From binnyjeshan@gmail.com Mon Nov 1 10:39:32 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 586123A69AC; Mon, 1 Nov 2010 10:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 042xeYMv2EpA; Mon, 1 Nov 2010 10:39:31 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 82B223A6949; Mon, 1 Nov 2010 10:39:31 -0700 (PDT) Received: by pxi13 with SMTP id 13so761489pxi.31 for ; Mon, 01 Nov 2010 10:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=eniwNmZpgKjqG7muQXRBmUcAdf/aquaUDvXuq1Wza7s=; b=qdrBKsmUArUknn2oG1fdXb181PJTHTGsJZYSTo6D805ktxiYx9I4ZOKSHCBhLWdTm4 48RNrUMF361RB7v0m6dRrnSNG2Z6y2gRvxrB51vZDbVYpG6iKjs3Rcsg8zk5leknVgwN ubzkL2gg4hDxXegTEmFKdrY3XRXbWNDTwZKlM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uDLBCtXapHP7rNjHnWrJOlpBbpunQDaxctgWPcHM9UN+YA6qN3oE4I2714oz9KMhBt CAiPOqi5sfYYpbiX1DhiCDHOz1XqcrQHZTgpTKzc6Uun8jYuzD/6yu0Yfx71PFSrNLbc /AK7mxFaG21NBnZDvxhcfy/0TQdvq/rOVYUCg= MIME-Version: 1.0 Received: by 10.142.253.21 with SMTP id a21mr4981355wfi.219.1288633173187; Mon, 01 Nov 2010 10:39:33 -0700 (PDT) Received: by 10.220.192.195 with HTTP; Mon, 1 Nov 2010 10:39:32 -0700 (PDT) In-Reply-To: References:

Date: Mon, 1 Nov 2010 23:09:32 +0530 Message-ID: Subject: Re: Regarding BFD Code Points for ACH header and MEP TLV for PW From: binny jeshan To: mpls-tp@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=00504502cccd88fbaa0494014a33 Cc: Mukund Mani 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, 01 Nov 2010 17:39:32 -0000 --00504502cccd88fbaa0494014a33 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, I am not able to find standard IANA allocations for the BFD ACH code points for differentiating CC and CV messages. Group members if any are aware of these standard values, kindly share. Kindly provide some reference if you have any. Thanks a lot, Binny. On 5 October 2010 19:09, Mukund Mani wrote: > Hello draft authors > > Could somebody please respond to this query. > > With Regards > Mukund > > > > > On Thu, Sep 30, 2010 at 1:02 PM, Mukund Mani wrote= : > >> Hello group >> >> >> >> >> >> 1. For BFD CC/CV, =93draft-ietf-mpls-tp-bfd-cc-cv-01=94 mentions abou= t >> separate code points for CC and CV in the ACH header. >> >> Considering the same how will the code points be defined for >> using BFD (CC/CV) on PW? >> Currently Channel Type (0x07) is the code point for BFD payloa= d >> and 0x21 that for IPv4 >> >> Thus for MPLS-TP PW we will need further code points to >> differentiate CC and CV for the VCCV payload types. >> >> >> >> >> >> 1. MEP TLV for PW will contain the AGI field which is of variable >> length. Will there be a separate sub-tlv for source MEP id in case of= PW. >> >> >> Will the above be defined in the next version of the draft? >> >> >> >> >> >> With Regards >> >> Mukund >> > > --00504502cccd88fbaa0494014a33 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello,

=A0

I am=A0not able to=A0find standard IANA allocations for the BFD ACH=A0= code points for differentiating=A0CC and CV messages. Group members if any = are aware of these standard values, kindly share.=A0Kindly provide some=A0r= eference if you have any.

=A0

Thanks a lot,

Binny.

On 5 October 2010 19:09, Mukund Mani <mukund.mani@gmail.com= > wrote:

Hello draft authors

=A0

Could somebody please respond to this query.

=A0

With Regards

Mukund

=A0

=A0

On Thu, Sep 30, 2010 at 1:02 PM, Mukund Mani <mukund.mani@gmail.com> wrote:

Hello group

=A0

=A0

For BFD CC/CV, =93draft-ietf-mp= ls-tp-bfd-cc-cv-01=94 mentions about separate code points for CC and CV in = the ACH header.

=A0=A0=A0=A0=A0=A0=A0=A0=A0 Conside= ring the same how will the code points be defined for using BFD (CC/CV) on = PW?

=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Currently Channel Type (0x07) is the code point for BFD payload a= nd 0x21 that for IPv4

=A0

=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Thus for MPLS-TP PW we will need further code points to different= iate CC and CV for the VCCV payload types.

=A0

=A0

MEP TLV for PW will contain the= AGI field which is of variable length. Will there be a separate sub-tlv fo= r source MEP id in case of PW.

=A0=A0=A0=A0=A0=A0=A0=A0=A0

Will the above be defined in the = next version of the draft?

=A0

=A0

With Regards

Mukund

--00504502cccd88fbaa0494014a33-- From apvelan@cisco.com Mon Nov 1 22:04:15 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 5BC463A679F for ; Mon, 1 Nov 2010 22:04:15 -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 7UvXUN23if6Q for ; Mon, 1 Nov 2010 22:04:14 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 11BCE3A6452 for ; Mon, 1 Nov 2010 22:04:14 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABc5z0xAaMHG/2dsb2JhbAChZXGiMZwMhUUEhFWJDQ X-IronPort-AV: E=Sophos;i="4.58,278,1286150400"; d="scan'208";a="210372195" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 02 Nov 2010 05:04:16 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA252pJj004293; Tue, 2 Nov 2010 05:04:15 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 10:34:14 +0530 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: draft-palanivelan-bfd-v2-gr-08 Date: Tue, 2 Nov 2010 10:34:12 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act3i65W1yk6Mk4jT46fkkpkBhpHuACuaQOw X-Priority: 1 Priority: Urgent Importance: high References:

<624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net>

From: "Palanivelan A (apvelan)" To: "Dave Katz" X-OriginalArrivalTime: 02 Nov 2010 05:04:14.0908 (UTC) FILETIME=[6531A7C0:01CB7A4B] Cc: rtg-bfd WG 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: Tue, 02 Nov 2010 05:04:15 -0000 To get started on this draft, This draft documents two issues with BFD and suggests a single solution to address both. 1) The first one is about the BFD failures during GRs in Planned Restarts, when co-existing with other Process intensive applications. This draft explains on such an issue, when scaled broadband configurations co-exist in the system that has routing protocols enabled with GR and BFD. Here, though the remote system (restarter) signals about the planned restart and the local system does get to know about the restart, during the restart, the local system still looks for BFD packets at the pre-negotiated timer values. Now, we have the tied routing protocol adjusting its timers to wait for an extended time (as negotiated for GR),but BFD still waiting for the originally negotiated timer values. Though this works fine in simple, less intensive environment, in a process intensive scenario, wherein I had given an example of BB configs in the draft, BFD may miss the packets, declare the remote neighbor down to the tied application (routing protocol) and hence bringing down the adjacency. This is also true for a system that has deep-packet inspection application like NBAR enabled in the system. I Have seen this in deployments with the products of the top-2 datacom companies and hence feel there is every reason to document and address this. For BFD to survive in such a scenario, The implementers look to use Flags/Timers or "Flags and Timers" to manage BFD timer values. Here again, though the timers are managed, there is no way of indicating at the local system that, the remote system is (gracefully) restarting. The local system anyway knows that the remote peer is restarting, why not have it in the diag field? And let that be set by the remote peer and why not have a bfd state indicating this state?. These two can be done within the existing framework of bfd (with additions to bfd diag and state). I thought negotiating the GR timers, between the peer makes it a much more standardized way of doing it and hence suggested the same in this draft. Not many would disagree to what I have said here, but whether this can be within the framework or not can be debated and also on whether this can be suggested as a BCP or otherwise. 2) The second one is about unplanned restarts and I see this working group is pretty much convinced that this problem won't be solved with what is suggested in this draft. Though I do think this extension would help solve the problem, I do not have it implemented anywhere to prove that it actually does. Appreciate your comments on my thoughts. Regards, A. Palanivelan -----Original Message----- From: Dave Katz [mailto:dkatz@juniper.net]=20 Sent: Friday, October 29, 2010 10:34 PM To: Palanivelan A (apvelan) Cc: rtg-bfd WG Subject: Re: draft-palanivelan-bfd-v2-gr-08 On Oct 29, 2010, at 12:33 AM, Palanivelan A (apvelan) wrote: > My experience with the process is not much to talk about but let me > confirm it is not easy even to get it to Historic :). > I loved to be part of working group in working through this document and > unfortunately it did not happen.=20 >=20 > Any good suggestions in how to go about, I would love to take it Dave. If the group thinks it to be worthwhile (I personally think it would be), it would be quite valuable to discuss the GR issues on this list, particularly any that you've run across that we did not foresee, with the goal of producing a BCP that more thoroughly documents how the various pieces of BFD and the control protocols might be pulled together to achieve GR. If you feel that our technical evaluation of your proposal is in error, or that the existing mechanisms are insufficient and yours adds value, that would be extremely helpful as well. Thanks, --Dave From nitinb@juniper.net Mon Nov 1 23:35:10 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 7C40D3A67D6 for ; Mon, 1 Nov 2010 23:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 r7hjoviOZRnD for ; Mon, 1 Nov 2010 23:35:08 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id DCB3B3A67CC for ; Mon, 1 Nov 2010 23:35:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTM+xHivY3ZgAgJMKLT7XHxbHu4fdxJUD@postini.com; Mon, 01 Nov 2010 23:35:11 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 1 Nov 2010 23:33:47 -0700 From: Nitin Bahadur To: "Palanivelan A (apvelan)" , Dave Katz Importance: high X-Priority: 1 Date: Mon, 1 Nov 2010 23:33:45 -0700 Subject: Re: draft-palanivelan-bfd-v2-gr-08 Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act3i65W1yk6Mk4jT46fkkpkBhpHuACuaQOwAASk6G0= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.4.0.100208 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rtg-bfd WG 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: Tue, 02 Nov 2010 06:35:10 -0000 Can u solve the first problem by bringing the BFD session administratively down on the router that is restarting? On an admin down, the remote peer should not affect the BFD clients...and the sessions also won't time out. Thanks Nitin On 11/1/10 10:04 PM, "Palanivelan A (apvelan)" wrote: > To get started on this draft, > This draft documents two issues with BFD and suggests a single solution > to address both. >=20 > 1) The first one is about the BFD failures during GRs in Planned > Restarts, when co-existing with other Process intensive applications. > This draft explains on such an issue, when scaled broadband > configurations co-exist in the system that has routing protocols enabled > with GR and BFD. > Here, though the remote system (restarter) signals about the planned > restart and the local system does get to know about the restart, during > the restart, > the local system still looks for BFD packets at the pre-negotiated timer > values. Now, we have the tied routing protocol adjusting its timers to > wait for an extended time (as negotiated for GR),but BFD still waiting > for the originally negotiated timer values. >=20 > Though this works fine in simple, less intensive environment, in a > process intensive scenario, wherein I had given an example of BB configs > in the draft, BFD may miss the packets, declare the remote neighbor down > to the tied application (routing protocol) and hence bringing down the > adjacency. This is also true for a system that has deep-packet > inspection application like NBAR enabled in the system. I Have seen this > in deployments with the products of the top-2 datacom companies and > hence feel there is every reason to document and address this. >=20 > For BFD to survive in such a scenario, The implementers look to use > Flags/Timers or "Flags and Timers" to manage BFD timer values. Here > again, though the timers are managed, there is no way of indicating at > the local system that, the remote system is (gracefully) restarting. The > local system anyway knows that the remote peer is restarting, why not > have it in the diag field? And let that be set by the remote peer and > why not have a bfd state indicating this state?. >=20 > These two can be done within the existing framework of bfd (with > additions to bfd diag and state). I thought negotiating the GR timers, > between the peer makes it a much more standardized way of doing it and > hence suggested the same in this draft. >=20 > Not many would disagree to what I have said here, but whether this can > be within the framework or not can be debated and also on whether this > can be suggested as a BCP or otherwise. >=20 > 2) The second one is about unplanned restarts and I see this working > group is pretty much convinced that this problem won't be solved with > what is suggested in this draft. > Though I do think this extension would help solve the problem, I do not > have it implemented anywhere to prove that it actually does. >=20 >=20 > Appreciate your comments on my thoughts. >=20 > Regards, > A. Palanivelan >=20 > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Friday, October 29, 2010 10:34 PM > To: Palanivelan A (apvelan) > Cc: rtg-bfd WG > Subject: Re: draft-palanivelan-bfd-v2-gr-08 >=20 >=20 > On Oct 29, 2010, at 12:33 AM, Palanivelan A (apvelan) wrote: >=20 >> My experience with the process is not much to talk about but let me >> confirm it is not easy even to get it to Historic :). >> I loved to be part of working group in working through this document > and >> unfortunately it did not happen. >>=20 >> Any good suggestions in how to go about, I would love to take it Dave. >=20 > If the group thinks it to be worthwhile (I personally think it would > be), it would be quite valuable to discuss the GR issues on this list, > particularly any that you've run across that we did not foresee, with > the goal of producing a BCP that more thoroughly documents how the > various pieces of BFD and the control protocols might be pulled together > to achieve GR. If you feel that our technical evaluation of your > proposal is in error, or that the existing mechanisms are insufficient > and yours adds value, that would be extremely helpful as well. >=20 > Thanks, >=20 > --Dave >=20 From jeff.tantsura@ericsson.com Tue Nov 2 09:19:54 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 4B70228C105 for ; Tue, 2 Nov 2010 09:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 75GvX9A8qGfk for ; Tue, 2 Nov 2010 09:19:53 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 4A60028C124 for ; Tue, 2 Nov 2010 09:19:53 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id oA2GJqih029959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Nov 2010 11:19:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.213]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 2 Nov 2010 12:19:55 -0400 From: Jeff Tantsura To: Nitin Bahadur , "Palanivelan A (apvelan)" , Dave Katz Date: Tue, 2 Nov 2010 12:19:46 -0400 Subject: RE: draft-palanivelan-bfd-v2-gr-08 Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act3i65W1yk6Mk4jT46fkkpkBhpHuACuaQOwAASk6G0AFHbswA== Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60A9EF900E5@EUSAACMS0701.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: rtg-bfd WG 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: Tue, 02 Nov 2010 16:19:54 -0000 +1 Regards, Jeff =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Nitin Bahadur Sent: Monday, November 01, 2010 23:34 To: Palanivelan A (apvelan); Dave Katz Cc: rtg-bfd WG Subject: Re: draft-palanivelan-bfd-v2-gr-08 Importance: High Can u solve the first problem by bringing the BFD session administratively down on the router that is restarting? On an admin down, the remote peer should not affect the BFD clients...and the sessions also won't time out. Thanks Nitin On 11/1/10 10:04 PM, "Palanivelan A (apvelan)" wrote: > To get started on this draft, > This draft documents two issues with BFD and suggests a single solution > to address both. >=20 > 1) The first one is about the BFD failures during GRs in Planned > Restarts, when co-existing with other Process intensive applications. > This draft explains on such an issue, when scaled broadband > configurations co-exist in the system that has routing protocols enabled > with GR and BFD. > Here, though the remote system (restarter) signals about the planned > restart and the local system does get to know about the restart, during > the restart, > the local system still looks for BFD packets at the pre-negotiated timer > values. Now, we have the tied routing protocol adjusting its timers to > wait for an extended time (as negotiated for GR),but BFD still waiting > for the originally negotiated timer values. >=20 > Though this works fine in simple, less intensive environment, in a > process intensive scenario, wherein I had given an example of BB configs > in the draft, BFD may miss the packets, declare the remote neighbor down > to the tied application (routing protocol) and hence bringing down the > adjacency. This is also true for a system that has deep-packet > inspection application like NBAR enabled in the system. I Have seen this > in deployments with the products of the top-2 datacom companies and > hence feel there is every reason to document and address this. >=20 > For BFD to survive in such a scenario, The implementers look to use > Flags/Timers or "Flags and Timers" to manage BFD timer values. Here > again, though the timers are managed, there is no way of indicating at > the local system that, the remote system is (gracefully) restarting. The > local system anyway knows that the remote peer is restarting, why not > have it in the diag field? And let that be set by the remote peer and > why not have a bfd state indicating this state?. >=20 > These two can be done within the existing framework of bfd (with > additions to bfd diag and state). I thought negotiating the GR timers, > between the peer makes it a much more standardized way of doing it and > hence suggested the same in this draft. >=20 > Not many would disagree to what I have said here, but whether this can > be within the framework or not can be debated and also on whether this > can be suggested as a BCP or otherwise. >=20 > 2) The second one is about unplanned restarts and I see this working > group is pretty much convinced that this problem won't be solved with > what is suggested in this draft. > Though I do think this extension would help solve the problem, I do not > have it implemented anywhere to prove that it actually does. >=20 >=20 > Appreciate your comments on my thoughts. >=20 > Regards, > A. Palanivelan >=20 > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Friday, October 29, 2010 10:34 PM > To: Palanivelan A (apvelan) > Cc: rtg-bfd WG > Subject: Re: draft-palanivelan-bfd-v2-gr-08 >=20 >=20 > On Oct 29, 2010, at 12:33 AM, Palanivelan A (apvelan) wrote: >=20 >> My experience with the process is not much to talk about but let me >> confirm it is not easy even to get it to Historic :). >> I loved to be part of working group in working through this document > and >> unfortunately it did not happen. >>=20 >> Any good suggestions in how to go about, I would love to take it Dave. >=20 > If the group thinks it to be worthwhile (I personally think it would > be), it would be quite valuable to discuss the GR issues on this list, > particularly any that you've run across that we did not foresee, with > the goal of producing a BCP that more thoroughly documents how the > various pieces of BFD and the control protocols might be pulled together > to achieve GR. If you feel that our technical evaluation of your > proposal is in error, or that the existing mechanisms are insufficient > and yours adds value, that would be extremely helpful as well. >=20 > Thanks, >=20 > --Dave >=20 From apvelan@cisco.com Wed Nov 3 00:04: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 991803A67E7 for ; Wed, 3 Nov 2010 00:04:33 -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 d31pcEs2gByu for ; Wed, 3 Nov 2010 00:04:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DE9523A67F0 for ; Wed, 3 Nov 2010 00:04:31 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAASm0EyQ/khNgWdsb2JhbAChXRUBARYiIqBsm2GFRQSEVYkO X-IronPort-AV: E=Sophos;i="4.58,287,1286150400"; d="scan'208";a="68172836" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2010 07:04:37 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oA374665001673; Wed, 3 Nov 2010 07:04:37 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Nov 2010 12:34:36 +0530 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: draft-palanivelan-bfd-v2-gr-08 Date: Wed, 3 Nov 2010 12:34:28 +0530 Message-ID: In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF60A9EF900E5@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act3i65W1yk6Mk4jT46fkkpkBhpHuACuaQOwAASk6G0AFHbswAAd0tKg References: <0ED867EB33AB2B45AAB470D5A64CDBF60A9EF900E5@EUSAACMS0701.eamcs.ericsson.se> From: "Palanivelan A (apvelan)" To: "Jeff Tantsura" , "Nitin Bahadur" , "Dave Katz" X-OriginalArrivalTime: 03 Nov 2010 07:04:36.0475 (UTC) FILETIME=[5FFF14B0:01CB7B25] Cc: rtg-bfd WG 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, 03 Nov 2010 07:04:33 -0000 Nitin and Jeff, What we are looking at with the solution that you suggested is, turning off your feature so that it doesn't affect the tied application. For me, this is more a workaround/ temporary fix to the issue and why do you want to back-off than actually attacking the issue and solving it. Again, this doesn't scale too. When the restarter has say about more bfd sessions/neighbors, we will be adding more cycles to the restarter this way. If you look at any of the Graceful restart mechanisms, always the helpers do more work than the restarter (for the simple reason, in a scaled scenario, the helper gotto take care of one of its session and if this is on the restarter, it got to take care for as many connected neighbors). Ideally since we have the diag fields available in bfd, we infact should look to leverage it in managing better and hence have a complete control. Thanks and Regards, A.Palanivelan -----Original Message----- From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com]=20 Sent: Tuesday, November 02, 2010 9:50 PM To: Nitin Bahadur; Palanivelan A (apvelan); Dave Katz Cc: rtg-bfd WG Subject: RE: draft-palanivelan-bfd-v2-gr-08 +1 Regards, Jeff =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Monday, November 01, 2010 23:34 To: Palanivelan A (apvelan); Dave Katz Cc: rtg-bfd WG Subject: Re: draft-palanivelan-bfd-v2-gr-08 Importance: High Can u solve the first problem by bringing the BFD session administratively down on the router that is restarting? On an admin down, the remote peer should not affect the BFD clients...and the sessions also won't time out. Thanks Nitin On 11/1/10 10:04 PM, "Palanivelan A (apvelan)" wrote: > To get started on this draft, > This draft documents two issues with BFD and suggests a single solution > to address both. >=20 > 1) The first one is about the BFD failures during GRs in Planned > Restarts, when co-existing with other Process intensive applications. > This draft explains on such an issue, when scaled broadband > configurations co-exist in the system that has routing protocols enabled > with GR and BFD. > Here, though the remote system (restarter) signals about the planned > restart and the local system does get to know about the restart, during > the restart, > the local system still looks for BFD packets at the pre-negotiated timer > values. Now, we have the tied routing protocol adjusting its timers to > wait for an extended time (as negotiated for GR),but BFD still waiting > for the originally negotiated timer values. >=20 > Though this works fine in simple, less intensive environment, in a > process intensive scenario, wherein I had given an example of BB configs > in the draft, BFD may miss the packets, declare the remote neighbor down > to the tied application (routing protocol) and hence bringing down the > adjacency. This is also true for a system that has deep-packet > inspection application like NBAR enabled in the system. I Have seen this > in deployments with the products of the top-2 datacom companies and > hence feel there is every reason to document and address this. >=20 > For BFD to survive in such a scenario, The implementers look to use > Flags/Timers or "Flags and Timers" to manage BFD timer values. Here > again, though the timers are managed, there is no way of indicating at > the local system that, the remote system is (gracefully) restarting. The > local system anyway knows that the remote peer is restarting, why not > have it in the diag field? And let that be set by the remote peer and > why not have a bfd state indicating this state?. >=20 > These two can be done within the existing framework of bfd (with > additions to bfd diag and state). I thought negotiating the GR timers, > between the peer makes it a much more standardized way of doing it and > hence suggested the same in this draft. >=20 > Not many would disagree to what I have said here, but whether this can > be within the framework or not can be debated and also on whether this > can be suggested as a BCP or otherwise. >=20 > 2) The second one is about unplanned restarts and I see this working > group is pretty much convinced that this problem won't be solved with > what is suggested in this draft. > Though I do think this extension would help solve the problem, I do not > have it implemented anywhere to prove that it actually does. >=20 >=20 > Appreciate your comments on my thoughts. >=20 > Regards, > A. Palanivelan >=20 > -----Original Message----- > From: Dave Katz [mailto:dkatz@juniper.net] > Sent: Friday, October 29, 2010 10:34 PM > To: Palanivelan A (apvelan) > Cc: rtg-bfd WG > Subject: Re: draft-palanivelan-bfd-v2-gr-08 >=20 >=20 > On Oct 29, 2010, at 12:33 AM, Palanivelan A (apvelan) wrote: >=20 >> My experience with the process is not much to talk about but let me >> confirm it is not easy even to get it to Historic :). >> I loved to be part of working group in working through this document > and >> unfortunately it did not happen. >>=20 >> Any good suggestions in how to go about, I would love to take it Dave. >=20 > If the group thinks it to be worthwhile (I personally think it would > be), it would be quite valuable to discuss the GR issues on this list, > particularly any that you've run across that we did not foresee, with > the goal of producing a BCP that more thoroughly documents how the > various pieces of BFD and the control protocols might be pulled together > to achieve GR. If you feel that our technical evaluation of your > proposal is in error, or that the existing mechanisms are insufficient > and yours adds value, that would be extremely helpful as well. >=20 > Thanks, >=20 > --Dave >=20 From wei.hongbo@zte.com.cn Mon Nov 22 17:06:48 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 15A8828C0ED for ; Mon, 22 Nov 2010 17:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_72=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 aEZO4rAlFHav for ; Mon, 22 Nov 2010 17:06:46 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 644973A6B03 for ; Mon, 22 Nov 2010 17:06:45 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205956853516; Tue, 23 Nov 2010 09:04:22 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 18019.2962247532; Tue, 23 Nov 2010 09:03:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id oAN17Wra070049; Tue, 23 Nov 2010 09:07:33 +0800 (CST) (envelope-from wei.hongbo@zte.com.cn) To: dkatz@juniper.net, dward@juniper.net Subject: Questions on RFC5880 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.hongbo@zte.com.cn Date: Tue, 23 Nov 2010 09:05:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-11-23 09:07:27, Serialize complete at 2010-11-23 09:07:27 Content-Type: multipart/alternative; boundary="=_alternative 00063655482577E4_=" X-MAIL: mse2.zte.com.cn oAN17Wra070049 Cc: rtg-bfd WG 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: Tue, 23 Nov 2010 01:06:48 -0000 This is a multipart message in MIME format. --=_alternative 00063655482577E4_= Content-Type: text/plain; charset="US-ASCII" Hello Daves and All, I have some questions regarding the BFD protocol, In RFC5880 "section 6.8.3 Timer Manipulation" written: >>> When bfd.SessionState is not Up, the system MUST set >>> bfd.DesiredMinTxInterval to a value of not less than one second >>> (1,000,000 microseconds). Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), the DisiredMinTxInterval field in the Control packets will change to the configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a Poll Sequence here? >>> In any case other than those explicitly called out above, timing >>> parameter changes MUST be effected immediately (changing the >>> transmission rate and/or the Detection Time). Q2: If the local system reduces it transmit interval (eg. Tx: 100ms -> 50ms) and initiate a Poll Sequence (send Control packet with P bit set), Can we immediately change the local system's Tx interval before we receive the Control packet with F bit set from the remote? Q3: Regard to the Poll Sequence, one system will receive the Control packet with P bit set and then start to detect; the remote system will receive the Control packet with F bit set and then start to detect. The differece between the two system's start point is the transmit time of Control packet with F bit set. But, The Tx interval becomes smaller and smaller(eg. some Vendors support 10ms), the transmit time of Control packet with F bit set MAY larger than the calculated Detection time. Do we need some private trick to fix that? Best regards, steven -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00063655482577E4_= Content-Type: text/html; charset="US-ASCII"
Hello Daves and All,

I have some questions regarding the BFD protocol, In RFC5880 "section 6.8.3 Timer Manipulation" written:

>>> When bfd.SessionState is not Up, the system MUST set >>> bfd.DesiredMinTxInterval to a value of not less than one second >>> (1,000,000 microseconds).

Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), the DisiredMinTxInterval field in the Control packets will change to the configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a Poll Sequence here?

>>> In any case other than those explicitly called out above, timing >>> parameter changes MUST be effected immediately (changing the >>> transmission rate and/or the Detection Time).

Q2: If the local system reduces it transmit interval (eg. Tx: 100ms -> 50ms) and initiate a Poll Sequence (send Control packet with P bit set), Can we immediately change
the local system's Tx interval before we receive the Control packet with F bit set from the remote?

Q3: Regard to the Poll Sequence, one system will receive the Control packet with P bit set and then start to detect; the remote system will receive the Control packet with
F bit set and then start to detect. The differece between the two system's start point is the transmit time of Control packet with F bit set.
But, The Tx interval becomes smaller and smaller(eg. some Vendors support 10ms), the transmit time of Control packet with F bit set MAY larger than the calculated Detection time. Do we need some private trick to fix that?

Best regards,
steven

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--=_alternative 00063655482577E4_=-- From dkatz@juniper.net Mon Nov 22 21:57: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 47E763A6B20 for ; Mon, 22 Nov 2010 21:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_72=0.6, 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 oWIR-Q0GCU4m for ; Mon, 22 Nov 2010 21:57:56 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 0FF4B3A6B1F for ; Mon, 22 Nov 2010 21:57:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTOtYGoA4+c2UncP1VKLeemm7kPC9MHd1@postini.com; Mon, 22 Nov 2010 21:58:53 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 22 Nov 2010 21:54:08 -0800 Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id oAN5s7b40630; Mon, 22 Nov 2010 21:54:07 -0800 (PST) (envelope-from dkatz@juniper.net) Subject: Re: Questions on RFC5880 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary="Apple-Mail-14-799318036" From: Dave Katz In-Reply-To: Date: Mon, 22 Nov 2010 21:54:06 -0800 Message-ID: <323CE2A0-605F-4F30-87DB-82FDB6C69BBF@juniper.net> References: To: X-Mailer: Apple Mail (2.1082) Cc: rtg-bfd WG , dward@juniper.net 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: Tue, 23 Nov 2010 05:57:57 -0000 --Apple-Mail-14-799318036 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Nov 22, 2010, at 5:05 PM, wei.hongbo@zte.com.cn wrote: >=20 > Hello Daves and All,=20 >=20 > I have some questions regarding the BFD protocol, In RFC5880 "section = 6.8.3 Timer Manipulation" written:=20 >=20 > >>> When bfd.SessionState is not Up, the system MUST set > >>> bfd.DesiredMinTxInterval to a value of not less than one second > >>> (1,000,000 microseconds).=20 >=20 > Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), = the DisiredMinTxInterval field in the Control packets will change to the = configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a = Poll Sequence here?=20 Yes. >=20 > >>> In any case other than those explicitly called out above, timing > >>> parameter changes MUST be effected immediately (changing the > >>> transmission rate and/or the Detection Time).=20 >=20 > Q2: If the local system reduces it transmit interval (eg. Tx: 100ms -> = 50ms) and initiate a Poll Sequence (send Control packet with P bit set), = Can we immediately change=20 > the local system's Tx interval before we receive the Control packet = with F bit set from the remote?=20 Yes, you must do so, because the receive side will be cranking down its = detection time; if, for instance, you were going from 1 sec to 50 msec, = the remote end will change its detection time to 150 msec and the = session would time out. >=20 > Q3: Regard to the Poll Sequence, one system will receive the Control = packet with P bit set and then start to detect; the remote system will = receive the Control packet with=20 > F bit set and then start to detect. The differece between the two = system's start point is the transmit time of Control packet with F bit = set.=20 > But, The Tx interval becomes smaller and smaller(eg. some Vendors = support 10ms), the transmit time of Control packet with F bit set MAY = larger than the calculated Detection time. Do we need some private trick = to fix that?=20 No; the round-trip time of the poll sequence can be longer than a = detection time. The important point, as you sensed in the second = question, is that if the remote system's detection time is going to drop = as a result of the local system reducing its TX interval, the local = system must start sending at the faster rate at the same time. This = will ensure that the remote end doesn't time out. The only case where the timing of the poll sequence matters is in Demand = Mode, because there otherwise is no control traffic; if the round-trip = time is greater than the detection time, the session will always time = out (see section 6.6). --Dave >=20 > Best regards, > steven >=20 >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Apple-Mail-14-799318036 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"

On Nov 22, 2010, at 5:05 PM, wei.hongbo@zte.com.cn wrote:

Hello Daves and All,

I have some questions regarding the BFD protocol, In RFC5880 "section 6.8.3 Timer Manipulation" written:

>>> When bfd.SessionState is not Up, the system MUST set >>> bfd.DesiredMinTxInterval to a value of not less than one second >>> (1,000,000 microseconds).

Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), the DisiredMinTxInterval field in the Control packets will change to the configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a Poll Sequence here?

Yes.

>>> In any case other than those explicitly called out above, timing >>> parameter changes MUST be effected immediately (changing the >>> transmission rate and/or the Detection Time).

Q2: If the local system reduces it transmit interval (eg. Tx: 100ms -> 50ms) and initiate a Poll Sequence (send Control packet with P bit set), Can we immediately change
the local system's Tx interval before we receive the Control packet with F bit set from the remote?

Yes, you must do so, because the receive side will be cranking down its detection time; if, for instance, you were going from 1 sec to 50 msec, the remote end will change its detection time to 150 msec and the session would time out.

Q3: Regard to the Poll Sequence, one system will receive the Control packet with P bit set and then start to detect; the remote system will receive the Control packet with
F bit set and then start to detect. The differece between the two system's start point is the transmit time of Control packet with F bit set.
But, The Tx interval becomes smaller and smaller(eg. some Vendors support 10ms), the transmit time of Control packet with F bit set MAY larger than the calculated Detection time. Do we need some private trick to fix that?

No; the round-trip time of the poll sequence can be longer than a detection time. The important point, as you sensed in the second question, is that if the remote system's detection time is going to drop as a result of the local system reducing its TX interval, the local system must start sending at the faster rate at the same time. This will ensure that the remote end doesn't time out.

The only case where the timing of the poll sequence matters is in Demand Mode, because there otherwise is no control traffic; if the round-trip time is greater than the detection time, the session will always time out (see section 6.6).

--Dave

Best regards,
steven

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--Apple-Mail-14-799318036-- From wwwhb2000@gmail.com Tue Nov 23 06:29:18 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 211883A6973 for ; Tue, 23 Nov 2010 06:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_72=0.6] 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 weleFb3-q-4y for ; Tue, 23 Nov 2010 06:29:15 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6E0E93A696C for ; Tue, 23 Nov 2010 06:29:15 -0800 (PST) Received: by iwn40 with SMTP id 40so10011518iwn.31 for ; Tue, 23 Nov 2010 06:30:13 -0800 (PST) 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:cc:content-type; bh=4cI4UvH6zsOCnFyMjnLfhq+4Ty5qM4XphL6Xdsm0E/8=; b=q/ccm7ry15mbv4kqEDuh9tjJ7LVARBi/0a6Ww2Qx2rgvBTnnm1HF/ObB+vs2b3/8yk K775+8ZlnVoZM0D2+PfKZDDc+IVjKXV7koKO99xLAMfhEG5ufcOlHNDjRYwLJqdElry5 3n2VYC43599QMNPa901d8T4w+49cy9e4SD02Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=pansJPe24ep3XZxjfrkSK2QCX+P82iU0M9mRhPj41ZcMEwrgwQCZgR9Ms9G10+kfvI IZylrmD/1XaxrD0Irawrl5ik/1GFQsZt5roj1M+uGNq9JbWqM4/KIk3g21y6O/3qVbXP 4kUS1MpZkoLzMBmrZnU+iuf3eLtBbDl/KtXXc= MIME-Version: 1.0 Received: by 10.231.16.69 with SMTP id n5mr8336684iba.5.1290522611669; Tue, 23 Nov 2010 06:30:11 -0800 (PST) Received: by 10.231.37.76 with HTTP; Tue, 23 Nov 2010 06:30:11 -0800 (PST) Date: Tue, 23 Nov 2010 22:30:11 +0800 Message-ID: Subject: RESEND: Re: Questions on RFC5880 From: HongBo Wei To: dkatz@juniper.net Content-Type: multipart/alternative; boundary=00221534d4bfd7dcbb0495b93549 Cc: rtg-bfd@ietf.org, dward@juniper.net 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: Tue, 23 Nov 2010 14:29:18 -0000 --00221534d4bfd7dcbb0495b93549 Content-Type: text/plain; charset=ISO-8859-1 Hi Dave, Thanks for your clarification. Additional question about the Poll Sequence: (eg. bfd.SessionState is Up, Tx interval is 100msec, Now we want to change the Tx interval to 50msec) -- Option 1: the local system send BFD Control Packets with the Poll bit set every 50msec; when recieved BFD Control Packets with the Final bit set, the local system send BFD Control Packets with the Poll bit clear every 50msec. -- Option 2: the local system send BFD Control Packets with the Poll bit clear every 50msec; At the same time, the local system send BFD Control Packets with the Poll bit set every 1sec; when we recieved BFD Control Packets with the Final bit set from remote, the local system terminate BFD Control Packets with the Poll bit set, and calculate the Detection time. I prefer to Option 1. What do you think about this? Best regards, steven On Nov 22, 2010, at 5:05 PM, wei.hongbo at zte.com.cnwrote: Hello Daves and All, I have some questions regarding the BFD protocol, In RFC5880 "section 6.8.3 Timer Manipulation" written: >>> When bfd.SessionState is not Up, the system MUST set >>> bfd.DesiredMinTxInterval to a value of not less than one second >>> (1,000,000 microseconds). Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), the DisiredMinTxInterval field in the Control packets will change to the configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a Poll Sequence here? Yes. >>> In any case other than those explicitly called out above, timing >>> parameter changes MUST be effected immediately (changing the >>> transmission rate and/or the Detection Time). Q2: If the local system reduces it transmit interval (eg. Tx: 100ms -> 50ms) and initiate a Poll Sequence (send Control packet with P bit set), Can we immediately change the local system's Tx interval before we receive the Control packet with F bit set from the remote? Yes, you must do so, because the receive side will be cranking down its detection time; if, for instance, you were going from 1 sec to 50 msec, the remote end will change its detection time to 150 msec and the session would time out. Q3: Regard to the Poll Sequence, one system will receive the Control packet with P bit set and then start to detect; the remote system will receive the Control packet with F bit set and then start to detect. The differece between the two system's start point is the transmit time of Control packet with F bit set. But, The Tx interval becomes smaller and smaller(eg. some Vendors support 10ms), the transmit time of Control packet with F bit set MAY larger than the calculated Detection time. Do we need some private trick to fix that? No; the round-trip time of the poll sequence can be longer than a detection time. The important point, as you sensed in the second question, is that if the remote system's detection time is going to drop as a result of the local system reducing its TX interval, the local system must start sending at the faster rate at the same time. This will ensure that the remote end doesn't time out. The only case where the timing of the poll sequence matters is in Demand Mode, because there otherwise is no control traffic; if the round-trip time is greater than the detection time, the session will always time out (see section 6.6). --Dave Best regards, steven -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --00221534d4bfd7dcbb0495b93549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave,

Thanks for your clarificatio= n.

=A0

Additional question about th= e Poll Sequence: (eg. bfd.SessionState is Up, Tx interval is 100msec, Now w= e want to change the Tx interval to 50msec)

=A0

-- Option = 1: the local system send BFD Control Packets with the Poll bit set every 50= msec; when recieved BFD Control Packets with the Final bit set, the local s= ystem send BFD Control Packets with the Poll bit clear every 50msec.=

=A0=

-- Option = 2: the local system send BFD Control Packets with the Poll bit clear every = 50msec; At the same time, the local system send BFD Control Packets with th= e Poll bit set every 1sec; when we recieved BFD Control Packets with the Fi= nal bit set from remote, the local system terminate BFD Control Packets wit= h the Poll bit set, and calculate the Detection time.

=A0

I prefer to Option 1. What d= o you think about this?

=A0

Best regards,
steven

=A0

On Nov 22, 2010, at 5:05 PM, wei.hongbo at zte.com.cn wrot= e:

Hello Daves and All= ,

I have some questions regarding = the BFD protocol, In RFC5880 "section 6.8.3 Timer Manipulation" w= ritten:

>>> When bfd.SessionState is not Up, the = system MUST set >>> bfd.DesiredMinTxInterval to a value of not = less than one second >>> (1,000,000 microseconds). =

Q1: When the bfd= .SessionState changed from INIT to UP(or DOWN->UP), the DisiredMinTxInte= rval field in the Control packets will change to the configured parameter (= eg, 50ms). So, the Tx Value changed. Do we need a Poll Sequence here?

Yes.

>>> In any case= other than those explicitly called out above, timing >>> param= eter changes MUST be effected immediately (changing the >>> tra= nsmission rate and/or the Detection Time).

Q2: If the local= system reduces it transmit interval (eg. Tx: 100ms -> 50ms) and initiat= e a Poll Sequence (send Control packet with P bit set), Can we immediately = change
the local system'= ;s Tx interval before we receive the Control packet with F bit set from the= remote?

Yes, you must do so, because the receive side will be cranki= ng down its detection time; =A0if, for instance, you were going from 1 sec = to 50 msec, the remote end will change its detection time to 150 msec and t= he session would time out.

<= font color=3D"#0000e0" face=3D"sans-serif" size=3D"2">Q3: Regard to the Pol= l Sequence, one system will receive the Control packet with P bit set and t= hen start to detect; the remote system will receive the Control packet with=
F bit set and then s= tart to detect. The differece between the two system's start point is t= he transmit time of Control packet with F bit set.
=A0 =A0 But, The Tx interval be= comes smaller and smaller(eg. some Vendors support 10ms), the transmit time= of Control packet with F bit set MAY larger than the calculated Detection = time. Do we need some private trick to fix that?

No; =A0the round-trip time of the poll sequence can be longe= r than a detection time. =A0The important point, as you sensed in the secon= d question, is that if the remote system's detection time is going to d= rop as a result of the local system reducing its TX interval, the local sys= tem must start sending at the faster rate at the same time. =A0This will en= sure that the remote end doesn't time out.

The only case where the timing of the poll sequence matters is in Dema= nd Mode, because there otherwise is no control traffic; =A0if the round-tri= p time is greater than the detection time, the session will always time out= (see section 6.6).

--Dave

Best reg= ards,
steven

------------------------------------=
--------------------
ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0in=
=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organiz=
ation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0na=
med=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=
=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=
=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confiden=
tial=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0=
or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0recei=
ved=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0of=
=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0t=
hose=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0Z=
TE=A0Anti-Spam=A0system.

--00221534d4bfd7dcbb0495b93549-- From spencer.giacalone@gmail.com Tue Nov 23 07:42:30 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 7823328C1BF for ; Tue, 23 Nov 2010 07:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 52z0gt7tBjh2 for ; Tue, 23 Nov 2010 07:42:29 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4BD8428C10C for ; Tue, 23 Nov 2010 07:34:36 -0800 (PST) Received: by iwn40 with SMTP id 40so10074215iwn.31 for ; Tue, 23 Nov 2010 07:35:33 -0800 (PST) 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:content-transfer-encoding; bh=quWvhsfsG3S9gEFiHSguWYWte4pRGRAHgdvbIq0Hwfw=; b=RJWHBWRIceH1HCbB/rD1l/AstQiUGpe18e5V9iwy4Hjrb3iyXLNFZe29o8C75g/yAb EDLL40ABJqhKR+D94L10YzEUYYYsF27oPNn+KzP9JRyTo1hlDeoMxsp/IKnsiUDJYpN3 0e69vqmcMxD5kjzeC8zLi/51b7m5yeljReipY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=cqdwDc43Qjdqb3soi3hp6BYPK5jCDHWSuM7Cx7+qIxpn4moM4LgOmY5LbXAZnLlmYk UaMKLQKCw1tCPAGSNxFDmJKlnmIli3o1bpflq1UxMWh1b2DacoY/Ym9Dwa105KSKPsgK HZ08Ipt4h3cP6FNjTiJKntlI53Vj7QS4zDVc0= MIME-Version: 1.0 Received: by 10.231.35.202 with SMTP id q10mr8456190ibd.88.1290526533694; Tue, 23 Nov 2010 07:35:33 -0800 (PST) Received: by 10.231.169.76 with HTTP; Tue, 23 Nov 2010 07:35:33 -0800 (PST) Date: Tue, 23 Nov 2010 10:35:33 -0500 Message-ID: Subject: New Draft- BFD Express Path From: Spencer Giacalone To: rtg-bfd@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Tue, 23 Nov 2010 15:42:30 -0000 Dear WG, A new draft, called =93BFD Express Path=94 (draft-giacalone-bfd-express-path-00) has been submitted for review. The primary intent of this draft is to mitigate capability gaps and exploit opportunities in certain performance sensitive networks. BFD Express Path creates a scalable, flexible, and integrated framework for gathering detailed network performance information. This information could be used to influence routing or traffic engineering, or for other network management purposes. It is assumed that further drafts will provide routing protocol extensions. BFD Express Path is focused on real world issues, and is aimed at (for example) the production network that I am responsible for. I invite discussion, comments, or questions. The abstract is as follows, and the draft itself is posted on the WG page: =93In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) have become (or are becoming) as (or more) critical to data path selection than other metrics. This document describes extensions to the BFD protocol, such that network performance information can be gathered in a scalable fashion, and subsequently used (by other protocols) to make path selection decisions. These extensions will also provide granular performance monitoring information.=94 Regards, Spencer From dkatz@juniper.net Tue Nov 23 08:29:54 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 D28D728B56A for ; Tue, 23 Nov 2010 08:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_72=0.6, 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 Tl1z00ycNbvA for ; Tue, 23 Nov 2010 08:29:52 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 6FB813A6974 for ; Tue, 23 Nov 2010 08:29:52 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTOvsORhOaaQnHCHXqkBQSmSJv80aVcYj@postini.com; Tue, 23 Nov 2010 08:30:50 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 23 Nov 2010 08:28:19 -0800 Received: from nimbus-sc.juniper.net (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id oANGSIb54098; Tue, 23 Nov 2010 08:28:18 -0800 (PST) (envelope-from dkatz@juniper.net) Subject: Re: Questions on RFC5880 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary="Apple-Mail-15-837369363" From: Dave Katz In-Reply-To: Date: Tue, 23 Nov 2010 08:28:18 -0800 Message-ID: <12F2FAAE-4D84-4E5B-9888-F5D971528918@juniper.net> References: To: HongBo Wei X-Mailer: Apple Mail (2.1082) Cc: rtg-bfd@ietf.org, dward@juniper.net 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: Tue, 23 Nov 2010 16:29:55 -0000 --Apple-Mail-15-837369363 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Nov 23, 2010, at 5:59 AM, HongBo Wei wrote: > Hi Dave, > Thanks for your clarification. > =20 > Additional question about the Poll Sequence: (eg. bfd.SessionState is = Up, Tx interval is 100msec, Now we want to change the Tx interval to = 50msec) > =20 > -- Option 1: the local system send BFD Control Packets with the Poll = bit set every 50msec; when recieved BFD Control Packets with the Final = bit set, the local system send BFD Control Packets with the Poll bit = clear every 50msec. > =20 > -- Option 2: the local system send BFD Control Packets with the Poll = bit clear every 50msec; At the same time, the local system send BFD = Control Packets with the Poll bit set every 1sec; when we recieved BFD = Control Packets with the Final bit set from remote, the local system = terminate BFD Control Packets with the Poll bit set, and calculate the = Detection time. > =20 > I prefer to Option 1. What do you think about this? Option 2 adds nothing but complexity... --Dave > =20 > Best regards, > steven > =20 > On Nov 22, 2010, at 5:05 PM, wei.hongbo at zte.com.cn wrote: >=20 >>=20 >> Hello Daves and All,=20 >>=20 >> I have some questions regarding the BFD protocol, In RFC5880 "section = 6.8.3 Timer Manipulation" written:=20 >>=20 >> >>> When bfd.SessionState is not Up, the system MUST set >> >>> bfd.DesiredMinTxInterval to a value of not less than one second >> >>> (1,000,000 microseconds).=20 >>=20 >> Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), = the DisiredMinTxInterval field in the Control packets will change to the = configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a = Poll Sequence here?=20 >=20 > Yes. >=20 >>=20 >> >>> In any case other than those explicitly called out above, timing >> >>> parameter changes MUST be effected immediately (changing the >> >>> transmission rate and/or the Detection Time).=20 >>=20 >> Q2: If the local system reduces it transmit interval (eg. Tx: 100ms = -> 50ms) and initiate a Poll Sequence (send Control packet with P bit = set), Can we immediately change=20 >> the local system's Tx interval before we receive the Control packet = with F bit set from the remote?=20 >=20 > Yes, you must do so, because the receive side will be cranking down = its detection time; if, for instance, you were going from 1 sec to 50 = msec, the remote end will change its detection time to 150 msec and the = session would time out. >=20 >>=20 >> Q3: Regard to the Poll Sequence, one system will receive the Control = packet with P bit set and then start to detect; the remote system will = receive the Control packet with=20 >> F bit set and then start to detect. The differece between the two = system's start point is the transmit time of Control packet with F bit = set.=20 >> But, The Tx interval becomes smaller and smaller(eg. some Vendors = support 10ms), the transmit time of Control packet with F bit set MAY = larger than the calculated Detection time. Do we need some private trick = to fix that?=20 >=20 > No; the round-trip time of the poll sequence can be longer than a = detection time. The important point, as you sensed in the second = question, is that if the remote system's detection time is going to drop = as a result of the local system reducing its TX interval, the local = system must start sending at the faster rate at the same time. This = will ensure that the remote end doesn't time out. >=20 > The only case where the timing of the poll sequence matters is in = Demand Mode, because there otherwise is no control traffic; if the = round-trip time is greater than the detection time, the session will = always time out (see section 6.6). >=20 > --Dave >=20 >>=20 >> Best regards, >> steven >>=20 >>=20 >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. >> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. --Apple-Mail-15-837369363 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"

On Nov 23, 2010, at 5:59 AM, HongBo Wei wrote:

Hi Dave,

Thanks for your clarification.

Additional question about the Poll Sequence: (eg. bfd.SessionState is Up, Tx interval is 100msec, Now we want to change the Tx interval to 50msec)

-- Option 1: the local system send BFD Control Packets with the Poll bit set every 50msec; when recieved BFD Control Packets with the Final bit set, the local system send BFD Control Packets with the Poll bit clear every 50msec.

-- Option 2: the local system send BFD Control Packets with the Poll bit clear every 50msec; At the same time, the local system send BFD Control Packets with the Poll bit set every 1sec; when we recieved BFD Control Packets with the Final bit set from remote, the local system terminate BFD Control Packets with the Poll bit set, and calculate the Detection time.

I prefer to Option 1. What do you think about this?

Option 2 adds nothing but complexity...

--Dave

Best regards,
steven

On Nov 22, 2010, at 5:05 PM, wei.hongbo at zte.com.cn wrote:

Hello Daves and All,

I have some questions regarding the BFD protocol, In RFC5880 "section 6.8.3 Timer Manipulation" written:

>>> When bfd.SessionState is not Up, the system MUST set >>> bfd.DesiredMinTxInterval to a value of not less than one second >>> (1,000,000 microseconds).

Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), the DisiredMinTxInterval field in the Control packets will change to the configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a Poll Sequence here?

Yes.

>>> In any case other than those explicitly called out above, timing >>> parameter changes MUST be effected immediately (changing the >>> transmission rate and/or the Detection Time).

Q2: If the local system reduces it transmit interval (eg. Tx: 100ms -> 50ms) and initiate a Poll Sequence (send Control packet with P bit set), Can we immediately change
the local system's Tx interval before we receive the Control packet with F bit set from the remote?

Yes, you must do so, because the receive side will be cranking down its detection time; if, for instance, you were going from 1 sec to 50 msec, the remote end will change its detection time to 150 msec and the session would time out.

Q3: Regard to the Poll Sequence, one system will receive the Control packet with P bit set and then start to detect; the remote system will receive the Control packet with
F bit set and then start to detect. The differece between the two system's start point is the transmit time of Control packet with F bit set.
But, The Tx interval becomes smaller and smaller(eg. some Vendors support 10ms), the transmit time of Control packet with F bit set MAY larger than the calculated Detection time. Do we need some private trick to fix that?

No; the round-trip time of the poll sequence can be longer than a detection time. The important point, as you sensed in the second question, is that if the remote system's detection time is going to drop as a result of the local system reducing its TX interval, the local system must start sending at the faster rate at the same time. This will ensure that the remote end doesn't time out.

The only case where the timing of the poll sequence matters is in Demand Mode, because there otherwise is no control traffic; if the round-trip time is greater than the detection time, the session will always time out (see section 6.6).

--Dave
Best regards,
steven
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--Apple-Mail-15-837369363-- From wwwhb2000@gmail.com Tue Nov 23 14:20:00 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 853E43A69B9 for ; Tue, 23 Nov 2010 14:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_72=0.6] 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 IfKGDsT2cmkv for ; Tue, 23 Nov 2010 14:19:58 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6F3D03A69A0 for ; Tue, 23 Nov 2010 14:19:58 -0800 (PST) Received: by iwn40 with SMTP id 40so10504807iwn.31 for ; Tue, 23 Nov 2010 14:20:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=x62+6ldZj/oJ+11gTnYOcXh5gW3qucfjJZSw6c7PZZY=; b=t/g4nnn1TK8e8UdOV3rSo4UrwvFk5/97X//45qYJ1huMle0v5fBv50xbjD1gHJiGZY neqPxGLaCIEfF2VBB8MJOgWK60ip3HF5X80A/E4TGaCX4Pm2veX9SRZDu+CYEhfyOf1t KPMxBw6UIy3MvzfRxvau6/VfEV1Mn1bLsfask= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=h126PHvFthmRAvCkIQbIigxzQqjZTHCYCvpF3MyFmI4LiCjE9X18TKb7399m/cL0iZ q1qD7+amgckrkt6D1c8FcVpRVIBoOqrBZFndVd4HX+EM+ZQib+DTMaZSnxZsf/4teGDa CRfWa62RrCLs3WTOv7+zqsErNHRQ2/24t6dxo= MIME-Version: 1.0 Received: by 10.231.40.10 with SMTP id i10mr8769383ibe.55.1290550855171; Tue, 23 Nov 2010 14:20:55 -0800 (PST) Received: by 10.231.37.76 with HTTP; Tue, 23 Nov 2010 14:20:55 -0800 (PST) In-Reply-To: <12F2FAAE-4D84-4E5B-9888-F5D971528918@juniper.net> References: <12F2FAAE-4D84-4E5B-9888-F5D971528918@juniper.net> Date: Wed, 24 Nov 2010 06:20:55 +0800 Message-ID: Subject: Re: Questions on RFC5880 From: "Wei.HongBo" To: Dave Katz Content-Type: multipart/alternative; boundary=000325575c5a497ec60495bfc953 Cc: rtg-bfd@ietf.org, dward@juniper.net 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: Tue, 23 Nov 2010 22:20:00 -0000 --000325575c5a497ec60495bfc953 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Dave, Thanks for your promptly response. Best regards, steven 2010/11/24 Dave Katz > > On Nov 23, 2010, at 5:59 AM, HongBo Wei wrote: > > Hi Dave, > Thanks for your clarification. > > Additional question about the Poll Sequence: (eg. bfd.SessionState is Up, > Tx interval is 100msec, Now we want to change the Tx interval to 50msec) > > -- Option 1: the local system send BFD Control Packets with the Poll bit > set every 50msec; when recieved BFD Control Packets with the Final bit se= t, > the local system send BFD Control Packets with the Poll bit clear every > 50msec. > > -- Option 2: the local system send BFD Control Packets with the Poll bit > clear every 50msec; At the same time, the local system send BFD Control > Packets with the Poll bit set every 1sec; when we recieved BFD Control > Packets with the Final bit set from remote, the local system terminate BF= D > Control Packets with the Poll bit set, and calculate the Detection time. > > I prefer to Option 1. What do you think about this? > > > Option 2 adds nothing but complexity... > > --Dave > > > Best regards, > steven > > On Nov 22, 2010, at 5:05 PM, wei.hongbo at zte.com.cnwrote: > > > Hello Daves and All, > > I have some questions regarding the BFD protocol, In RFC5880 "section 6.8= .3 > Timer Manipulation" written: > > >>> When bfd.SessionState is not Up, the system MUST set > >>> bfd.DesiredMinTxInterval to a value of not less than one second > >>> (1,000,000 microseconds). > > Q1: When the bfd.SessionState changed from INIT to UP(or DOWN->UP), the > DisiredMinTxInterval field in the Control packets will change to the > configured parameter (eg, 50ms). So, the Tx Value changed. Do we need a P= oll > Sequence here? > > > Yes. > > > >>> In any case other than those explicitly called out above, timing > >>> parameter changes MUST be effected immediately (changing the > >>> transmission rate and/or the Detection Time). > > Q2: If the local system reduces it transmit interval (eg. Tx: 100ms -> > 50ms) and initiate a Poll Sequence (send Control packet with P bit set), = Can > we immediately change > the local system's Tx interval before we receive the Control packet with = F > bit set from the remote? > > > Yes, you must do so, because the receive side will be cranking down its > detection time; if, for instance, you were going from 1 sec to 50 msec, = the > remote end will change its detection time to 150 msec and the session wou= ld > time out. > > > Q3: Regard to the Poll Sequence, one system will receive the Control pack= et > with P bit set and then start to detect; the remote system will receive t= he > Control packet with > F bit set and then start to detect. The differece between the two system'= s > start point is the transmit time of Control packet with F bit set. > But, The Tx interval becomes smaller and smaller(eg. some Vendors > support 10ms), the transmit time of Control packet with F bit set MAY lar= ger > than the calculated Detection time. Do we need some private trick to fix > that? > > > No; the round-trip time of the poll sequence can be longer than a > detection time. The important point, as you sensed in the second questio= n, > is that if the remote system's detection time is going to drop as a resul= t > of the local system reducing its TX interval, the local system must start > sending at the faster rate at the same time. This will ensure that the > remote end doesn't time out. > > The only case where the timing of the poll sequence matters is in Demand > Mode, because there otherwise is no control traffic; if the round-trip t= ime > is greater than the detection time, the session will always time out (see > section 6.6). > > --Dave > > > Best regards, > steven > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > --000325575c5a497ec60495bfc953 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Dave,

=A0

Thanks for your promptly res= ponse.

Best regards,

steven

2010/11/24 Dave Katz <dkatz@juniper.net>

On Nov 23, 2010, at 5:59 AM, HongBo Wei wrote:

Hi Dave,

Thanks for your clarificatio= n.

=A0

Additional question about th= e Poll Sequence: (eg. bfd.SessionState is Up, Tx interval is 100msec, Now w= e want to change the Tx interval to 50msec)

=A0

-- Option = 1: the local system send BFD Control Packets with the Poll bit set every 50= msec; when recieved BFD Control Packets with the Final bit set, the local s= ystem send BFD Control Packets with the Poll bit clear every 50msec.=

=A0=

-- Option = 2: the local system send BFD Control Packets with the Poll bit clear every = 50msec; At the same time, the local system send BFD Control Packets with th= e Poll bit set every 1sec; when we recieved BFD Control Packets with the Fi= nal bit set from remote, the local system terminate BFD Control Packets wit= h the Poll bit set, and calculate the Detection time.

=A0

I prefer to Option 1. What d= o you think about this?

Option 2 adds nothing but complexity...

--Dave
=A0

Best regards,
steven

=A0

On Nov 22, 2010, at 5:05 PM, wei.hongbo at zte.com.cn wrot= e:

Hello Daves and All= ,

I have some questions regarding = the BFD protocol, In RFC5880 "section 6.8.3 Timer Manipulation" w= ritten:

>>> When bfd.SessionState is not Up, the = system MUST set >>> bfd.DesiredMinTxInterval to a value of not = less than one second >>> (1,000,000 microseconds). =

Q1: When the bfd= .SessionState changed from INIT to UP(or DOWN->UP), the DisiredMinTxInte= rval field in the Control packets will change to the configured parameter (= eg, 50ms). So, the Tx Value changed. Do we need a Poll Sequence here?

Yes.

>>> In any case= other than those explicitly called out above, timing >>> param= eter changes MUST be effected immediately (changing the >>> tra= nsmission rate and/or the Detection Time).

Q2: If the local= system reduces it transmit interval (eg. Tx: 100ms -> 50ms) and initiat= e a Poll Sequence (send Control packet with P bit set), Can we immediately = change
the local system'= ;s Tx interval before we receive the Control packet with F bit set from the= remote?

Yes, you must do so, because the receive side will be cranki= ng down its detection time; =A0if, for instance, you were going from 1 sec = to 50 msec, the remote end will change its detection time to 150 msec and t= he session would time out.

<= font color=3D"#0000e0" size=3D"2" face=3D"sans-serif">Q3: Regard to the Pol= l Sequence, one system will receive the Control packet with P bit set and t= hen start to detect; the remote system will receive the Control packet with=
F bit set and then s= tart to detect. The differece between the two system's start point is t= he transmit time of Control packet with F bit set.
=A0 =A0 But, The Tx interval be= comes smaller and smaller(eg. some Vendors support 10ms), the transmit time= of Control packet with F bit set MAY larger than the calculated Detection = time. Do we need some private trick to fix that?

No; =A0the round-trip time of the poll sequence can be longe= r than a detection time. =A0The important point, as you sensed in the secon= d question, is that if the remote system's detection time is going to d= rop as a result of the local system reducing its TX interval, the local sys= tem must start sending at the faster rate at the same time. =A0This will en= sure that the remote end doesn't time out.

The only case where the timing of the poll sequence matters is in Dema= nd Mode, because there otherwise is no control traffic; =A0if the round-tri= p time is greater than the detection time, the session will always time out= (see section 6.6).

--Dave
Best reg= ards,
steven
------------------------------------=
--------------------
ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0in=
=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organiz=
ation.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0na=
med=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=
=A0permitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=
=A0to=A0others.
This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confiden=
tial=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual=A0=
or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0recei=
ved=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0of=
=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0t=
hose=A0of=A0the=A0individual=A0sender.
This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by=A0Z=
TE=A0Anti-Spam=A0system.

--000325575c5a497ec60495bfc953-- From vishwas.ietf@gmail.com Tue Nov 23 16:22:46 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 DCF6E3A6987 for ; Tue, 23 Nov 2010 16:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 d0huRVAYaP1j for ; Tue, 23 Nov 2010 16:22:46 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id EDE623A69E1 for ; Tue, 23 Nov 2010 16:22:45 -0800 (PST) Received: by qwc9 with SMTP id 9so143163qwc.31 for ; Tue, 23 Nov 2010 16:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+1WnEfpJ1uZAPb7iI6Cp7+WL1eIpb0Qbv0IzoCkuWTY=; b=YT64xFJU40mgCo6kFMTm46spWx+plqS8qEuxGdcxfPNzOghyPl1z4HLWp/LvRaTBSV ps0hiDYUCA08TpKAcSsNx8hxQ91oc2PfZmciIgP/1diieV4N0oD0UP1x83gBvlLMsd82 3OEkCt05c2CjQQMuJxI3hRIkrdU4RfhsLHUXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Z8xWCYCLPqQZCBr8CfOt9Y7jPFdWjQcXlBBsK+NIz2vXKBnGzcGJsx2Zqyd8IIdXUg 7G8JrOqFG+IWd/oPnk4iBeZE5K3KLC0YMKCqxqyhUYZ01s8nSpuUQFd+iGY+29COKHtf mE2FR4uIryIWghrg8q5cIF0Nu1PCOVSM3/d/k= MIME-Version: 1.0 Received: by 10.229.233.18 with SMTP id jw18mr6800475qcb.192.1290558224074; Tue, 23 Nov 2010 16:23:44 -0800 (PST) Received: by 10.229.86.19 with HTTP; Tue, 23 Nov 2010 16:23:44 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Nov 2010 16:23:44 -0800 Message-ID: Subject: Re: New Draft- BFD Express Path From: Vishwas Manral To: Spencer Giacalone Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Wed, 24 Nov 2010 00:22:46 -0000 Spencer, I have some top level comments: 1. Do we need the functionality on a continuous basis or on a demand basis, when such delay measurements are required? 2. What happens to the authentication as with the A bit the packet seems to have the authentication field after the defined BFD packet. 3. Backward compatibility with existing implementations? 4. Is 1-way delay required or do we also need 2-way delay? There seem to be quite some work on the delay measurements in IPPM and MPLS-TP, you could try to use that effort. Thanks, Vishwas On Tue, Nov 23, 2010 at 7:35 AM, Spencer Giacalone wrote: > Dear WG, > > A new draft, called =93BFD Express Path=94 > (draft-giacalone-bfd-express-path-00) has been submitted for review. > The primary intent of this draft is to mitigate capability gaps and > exploit opportunities in certain performance sensitive networks. BFD > Express Path creates a scalable, flexible, and integrated framework > for gathering detailed network performance information. This > information could be used to influence routing or traffic engineering, > or for other network management purposes. It is assumed that further > drafts will provide routing protocol extensions. BFD Express Path is > focused on real world issues, and is aimed at (for example) the > production network that I am responsible for. I invite discussion, > comments, or questions. The abstract is as follows, and the draft > itself is posted on the WG page: > > =93In certain networks, such as, but not limited to, financial > information networks (e.g. stock market data providers), network > performance criteria (e.g. latency) have become (or are becoming) as > (or more) critical to data path selection than other metrics. This > document describes extensions to the BFD protocol, such that > network performance information can be gathered in a scalable fashion, > and subsequently used (by other protocols) to make path selection > decisions. These extensions will also provide granular performance > monitoring information.=94 > > Regards, > > Spencer > From mach@huawei.com Tue Nov 23 23:53: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 F30433A6989 for ; Tue, 23 Nov 2010 23:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 EvnbL94hLrDA for ; Tue, 23 Nov 2010 23:53:23 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B6C173A69A1 for ; Tue, 23 Nov 2010 23:53:23 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCD00LUQPX67L@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Wed, 24 Nov 2010 15:53:30 +0800 (CST) Received: from m55527c ([10.110.98.66]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCD00I4GPX5YN@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Wed, 24 Nov 2010 15:53:30 +0800 (CST) Date: Wed, 24 Nov 2010 15:53:29 +0800 From: Mach Chen Subject: Re: New Draft- BFD Express Path In-reply-to: To: Spencer Giacalone , rtg-bfd@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=windows-1252; reply-type=original Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: 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, 24 Nov 2010 07:53:25 -0000 Hi Spencer, I think using BFD for performance monitoring is a reasonable way. Two years ago, we wrote a draft for the same purpose with relevant BFD extensions, it could be found at: http://tools.ietf.org/html/draft-guo-bfd-pm-extension-01. The reason for choose BFD for performance monitoring is because BFD is a protocol independent technology, BFD-based solution would provide a general mechanism for performance monitoring, no matter what the path is IP, MPLS or other types. As Vishwas said in another email, you should consider the compatibility issue especially when you want to deploy BFD Authentication at the same time. Best regards, Mach -------------------------------------------------- From: "Spencer Giacalone" Sent: Tuesday, November 23, 2010 11:35 PM To: Subject: New Draft- BFD Express Path > Dear WG, > > A new draft, called �BFD Express Path� > (draft-giacalone-bfd-express-path-00) has been submitted for review. > The primary intent of this draft is to mitigate capability gaps and > exploit opportunities in certain performance sensitive networks. BFD > Express Path creates a scalable, flexible, and integrated framework > for gathering detailed network performance information. This > information could be used to influence routing or traffic engineering, > or for other network management purposes. It is assumed that further > drafts will provide routing protocol extensions. BFD Express Path is > focused on real world issues, and is aimed at (for example) the > production network that I am responsible for. I invite discussion, > comments, or questions. The abstract is as follows, and the draft > itself is posted on the WG page: > > �In certain networks, such as, but not limited to, financial > information networks (e.g. stock market data providers), network > performance criteria (e.g. latency) have become (or are becoming) as > (or more) critical to data path selection than other metrics. This > document describes extensions to the BFD protocol, such that > network performance information can be gathered in a scalable fashion, > and subsequently used (by other protocols) to make path selection > decisions. These extensions will also provide granular performance > monitoring information.� > > Regards, > > Spencer From mach@huawei.com Tue Nov 23 23:57:26 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 BDDBE3A69C6 for ; Tue, 23 Nov 2010 23:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 lnVTOh3ByPRg for ; Tue, 23 Nov 2010 23:57:25 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A84753A699C for ; Tue, 23 Nov 2010 23:57:25 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCD0095MQ2B6T@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Wed, 24 Nov 2010 15:56:36 +0800 (CST) Received: from m55527c ([10.110.98.66]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCD006PDQ2AYA@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Wed, 24 Nov 2010 15:56:35 +0800 (CST) Date: Wed, 24 Nov 2010 15:56:34 +0800 From: Mach Chen Subject: Re: New Draft- BFD Express Path In-reply-to: To: Vishwas Manral , Spencer Giacalone Message-id: <2E3DA42BF26E430D932CD9B046B1B210@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=windows-1252; reply-type=original Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: 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: Wed, 24 Nov 2010 07:57:26 -0000 Hi Vishwas, At present, IPPM is charterd to do active measurement, and MPLS-TP relevant meachanisms only apply to LSP. Best regards, Mach -------------------------------------------------- From: "Vishwas Manral" Sent: Wednesday, November 24, 2010 8:23 AM To: "Spencer Giacalone" Cc: Subject: Re: New Draft- BFD Express Path > Spencer, > > I have some top level comments: > > 1. Do we need the functionality on a continuous basis or on a demand > basis, when such delay measurements are required? > 2. What happens to the authentication as with the A bit the packet > seems to have the authentication field after the defined BFD packet. > 3. Backward compatibility with existing implementations? > 4. Is 1-way delay required or do we also need 2-way delay? > > There seem to be quite some work on the delay measurements in IPPM and > MPLS-TP, you could try to use that effort. > > Thanks, > Vishwas > > On Tue, Nov 23, 2010 at 7:35 AM, Spencer Giacalone > wrote: >> Dear WG, >> >> A new draft, called �BFD Express Path� >> (draft-giacalone-bfd-express-path-00) has been submitted for review. >> The primary intent of this draft is to mitigate capability gaps and >> exploit opportunities in certain performance sensitive networks. BFD >> Express Path creates a scalable, flexible, and integrated framework >> for gathering detailed network performance information. This >> information could be used to influence routing or traffic engineering, >> or for other network management purposes. It is assumed that further >> drafts will provide routing protocol extensions. BFD Express Path is >> focused on real world issues, and is aimed at (for example) the >> production network that I am responsible for. I invite discussion, >> comments, or questions. The abstract is as follows, and the draft >> itself is posted on the WG page: >> >> �In certain networks, such as, but not limited to, financial >> information networks (e.g. stock market data providers), network >> performance criteria (e.g. latency) have become (or are becoming) as >> (or more) critical to data path selection than other metrics. This >> document describes extensions to the BFD protocol, such that >> network performance information can be gathered in a scalable fashion, >> and subsequently used (by other protocols) to make path selection >> decisions. These extensions will also provide granular performance >> monitoring information.� >> >> Regards, >> >> Spencer >> From vishwas.ietf@gmail.com Wed Nov 24 10:17:35 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 4D1803A691E for ; Wed, 24 Nov 2010 10:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9AGX0JLh0KNr for ; Wed, 24 Nov 2010 10:17:34 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 54AA83A68E0 for ; Wed, 24 Nov 2010 10:17:34 -0800 (PST) Received: by yxk30 with SMTP id 30so18179yxk.31 for ; Wed, 24 Nov 2010 10:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PnkuAsyFvUMYoITcBCih2WJEkqb8SoJvHglCT0Ucpiw=; b=ikGGzvAhoaAlcJ+CMm+Z/8yVNgwcKZZzmnmCxGsIoMJkuh3exX82LmHEQK1SrQTvA/ DCfI9xG+G6af1ui0z0KBMDSpgd+vkzxoZLh6FnI4yxcPmkAJNRu6n+lyiHfzIU4Bp9Bb JCTFxxM6a5RHekeRNEpbKAExPggSeWMFBqgWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VeIWOQsPg0Ll3RvarZwZFwInfYhfIX06V3UNId96GFk6CUDBkcs+37w8FXkIZOAEsu E6eyXd3y/a8eE7Gs9LB5/FbHtnwbKJ/81GmeMZUwmPOrxuRTn02RQo4cPxfyN5EjW2Xk x2PBWUtvyJA0DaUoSvU+CcoUG0CB3s/BOe4lg= MIME-Version: 1.0 Received: by 10.150.147.7 with SMTP id u7mr1508420ybd.62.1290622714041; Wed, 24 Nov 2010 10:18:34 -0800 (PST) Received: by 10.150.186.17 with HTTP; Wed, 24 Nov 2010 10:18:33 -0800 (PST) In-Reply-To: <2E3DA42BF26E430D932CD9B046B1B210@m55527c> References: <2E3DA42BF26E430D932CD9B046B1B210@m55527c> Date: Wed, 24 Nov 2010 10:18:33 -0800 Message-ID: Subject: Re: New Draft- BFD Express Path From: Vishwas Manral To: Mach Chen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Wed, 24 Nov 2010 18:17:35 -0000 Hi Mach, I agree to the charters of IPPM and MPLS-TP, however looking at the draft I see they are passing a lot more details than just originator and receiver timestamps. My comment was that it could be looked at in greater detail. Thanks, Vishwas On Tue, Nov 23, 2010 at 11:56 PM, Mach Chen wrote: > Hi Vishwas, > > At present, IPPM is charterd to do active measurement, and MPLS-TP releva= nt > meachanisms only apply to LSP. > > Best regards, > Mach > > -------------------------------------------------- > From: "Vishwas Manral" > Sent: Wednesday, November 24, 2010 8:23 AM > To: "Spencer Giacalone" > Cc: > Subject: Re: New Draft- BFD Express Path > >> Spencer, >> >> I have some top level comments: >> >> 1. Do we need the functionality on a continuous basis or on a demand >> basis, when such delay measurements are required? >> 2. What happens to the authentication as with the A bit the packet >> seems to have the authentication field after the defined BFD packet. >> 3. Backward compatibility with existing implementations? >> 4. Is 1-way delay required or do we also need 2-way delay? >> >> There seem to be quite some work on the delay measurements in IPPM and >> MPLS-TP, you could try to use that effort. >> >> Thanks, >> Vishwas >> >> On Tue, Nov 23, 2010 at 7:35 AM, Spencer Giacalone >> wrote: >>> >>> Dear WG, >>> >>> A new draft, called =93BFD Express Path=94 >>> (draft-giacalone-bfd-express-path-00) has been submitted for review. >>> The primary intent of this draft is to mitigate capability gaps and >>> exploit opportunities in certain performance sensitive networks. BFD >>> Express Path creates a scalable, flexible, and integrated framework >>> for gathering detailed network performance information. This >>> information could be used to influence routing or traffic engineering, >>> or for other network management purposes. It is assumed that further >>> drafts will provide routing protocol extensions. BFD Express Path is >>> focused on real world issues, and is aimed at (for example) the >>> production network that I am responsible for. I invite discussion, >>> comments, or questions. The abstract is as follows, and the draft >>> itself is posted on the WG page: >>> >>> =93In certain networks, such as, but not limited to, financial >>> information networks (e.g. stock market data providers), network >>> performance criteria (e.g. latency) have become (or are becoming) as >>> (or more) critical to data path selection than other metrics. This >>> document describes extensions to the BFD protocol, such that >>> network performance information can be gathered in a scalable fashion, >>> and subsequently used (by other protocols) to make path selection >>> decisions. These extensions will also provide granular performance >>> monitoring information.=94 >>> >>> Regards, >>> >>> Spencer >>> > From spencer.giacalone@gmail.com Wed Nov 24 20:35:39 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 40E0A3A6893 for ; Wed, 24 Nov 2010 20:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 igBQbSZvRcMi for ; Wed, 24 Nov 2010 20:35:38 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CEB033A6996 for ; Wed, 24 Nov 2010 20:35:37 -0800 (PST) Received: by iwn40 with SMTP id 40so613840iwn.31 for ; Wed, 24 Nov 2010 20:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=26N1j5mcerI5OYv3M2StaUT6VIehgx6QbWO0QPzktjg=; b=Xf/dHyTP8J0Gl8AGh1+AZPiRTV1hgOJId0qHFZolR/HHnTN+tYEuV2SSFrMevHh9zm 0fM5F2q4iXctvc1hqxOZXyhxOqkYoeAJmpZaX3OtCV5qKsB9NEyF7FbIFMV20VdOHZxh rSYEtjWwwpMyY47UG2CStad2YyPvU7Bhe65DY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Wv7XLyHNSPVmvnFZjKuRb2PhNfVLFdBZrRxVY1PxhntE+yyE3vxbHysW3o51o70/Ge FZEJQNRXFD0zWJ+oXGyKqWFxG0haxcB2Mt8EU5XSnKNAWGqRmvxVvxTqUe/H54qnr2m9 GfAfZcIHPDuXmAVZK6oCaCQgyvIY9dyEe6VrM= MIME-Version: 1.0 Received: by 10.231.183.136 with SMTP id cg8mr204903ibb.63.1290659798448; Wed, 24 Nov 2010 20:36:38 -0800 (PST) Received: by 10.231.169.76 with HTTP; Wed, 24 Nov 2010 20:36:38 -0800 (PST) In-Reply-To: References: Date: Wed, 24 Nov 2010 23:36:38 -0500 Message-ID: Subject: Re: New Draft- BFD Express Path From: Spencer Giacalone To: Vishwas Manral Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Thu, 25 Nov 2010 04:35:39 -0000 Hi Vishwas, Thanks for your comments. My responses are inline. >1. Do we need the functionality on a continuous basis or on a demand >basis, when such delay measurements are required? BFD Express Path is meant to be an optional feature, to be enabled as needed. Certainly, not all users will need this functionality at all. When BFD Express Path is enabled, my assumption is that all BFD packets between two peers will include the Express Path extensions. Does that answer your question? >2. What happens to the authentication as with the A bit the packet >seems to have the authentication field after the defined BFD packet. >From a backwards compatibility perspective, would it be easier to leave the auth extension as the next field after the control packet (I am thinking the answer is yes)? I would prefer to auth the whole packet, for obvious reasons. From a hashing perspective, are there any issues with hashing the entire packet, including the Express Path extension, even if that extension is unknown (I don=92t see one)? >3. Backward compatibility with existing implementations? Section 7 in the draft deals with remote systems that do not support Express Path or a clock sync protocol (when the local system does). However, the reception of BFD Express Path packets on incompatible implementations is a valid point. There are two issues there- the new diag codes, and the extension itself. I don=92t see anything in 5880 on how the reception of unknown diag codes or extensions are to be handled. I was assuming that conditions like this are ignored, however, if this is implementation specific, of if I missed something, perhaps someone can shed light on this. That said, if we are using up diag codes in this manor, it might be better to use a single diag code (or some other bit) to denote the next header as a generic TLV. I am happy to write something up if the WG concludes that is the way to go. >4. Is 1-way delay required or do we also need 2-way delay? My thoughts are that different users will have different requirements, depending on what they are trying to do. My interpretation is that users who want 2-way delay on each node can use BFD Express Path in Echo Mode or set the P bit. The draft supports both (but not sure if all implementations can handle both). For control plane purposes, I am inclined to think 1-way delay is what is needed. >There seem to be quite some work on the delay measurements in IPPM and >MPLS-TP, you could try to use that effort. IPPM is an interesting point. To the degree that the IPPM WG has spelled out metrics, issues, and terms, BFD Express Path should/could be a complimentary framework for actually providing performance measurements. This is an example of why I left the actual timestamp field format TBD. Outside of that, I would prefer to use existing protocols, which we already run at granular packet intervals, to introducing a new protocol in our network. Since we already run BFD, I feel that it is almost perfectly placed to do this. In addition, having experience with end-to-end =93mesh based=94 monitoring protocols, I feel that the link-by-link approach in BFD Express Path is superior in a number of ways (though BFD Multihop, Express Path is mentioned in the draft). I am happy to expand on this last point. As a result of your comment, perhaps I will reach out to the IPPM chairs. Although my network is an in-sourced MPLS core, MPLS-TP is not on my deployment roadmap, as we do not require that functionality. I am happy to further this discussion. Let me know what you think, Spence > MPLS-TP, you could try to use that effort. > > Thanks, > Vishwas > > On Tue, Nov 23, 2010 at 7:35 AM, Spencer Giacalone > wrote: >> Dear WG, >> >> A new draft, called =93BFD Express Path=94 >> (draft-giacalone-bfd-express-path-00) has been submitted for review. >> The primary intent of this draft is to mitigate capability gaps and >> exploit opportunities in certain performance sensitive networks. BFD >> Express Path creates a scalable, flexible, and integrated framework >> for gathering detailed network performance information. This >> information could be used to influence routing or traffic engineering, >> or for other network management purposes. It is assumed that further >> drafts will provide routing protocol extensions. BFD Express Path is >> focused on real world issues, and is aimed at (for example) the >> production network that I am responsible for. I invite discussion, >> comments, or questions. The abstract is as follows, and the draft >> itself is posted on the WG page: >> >> =93In certain networks, such as, but not limited to, financial >> information networks (e.g. stock market data providers), network >> performance criteria (e.g. latency) have become (or are becoming) as >> (or more) critical to data path selection than other metrics. This >> document describes extensions to the BFD protocol, such that >> network performance information can be gathered in a scalable fashion, >> and subsequently used (by other protocols) to make path selection >> decisions. These extensions will also provide granular performance >> monitoring information.=94 >> >> Regards, >> >> Spencer >> > From kesavan.nav@gmail.com Thu Nov 25 08:55:12 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 E988A28C141 for ; Thu, 25 Nov 2010 08:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 3HbPUj+JTCIp for ; Thu, 25 Nov 2010 08:55:12 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1B1D028C0FC for ; Thu, 25 Nov 2010 08:55:12 -0800 (PST) Received: by gwj17 with SMTP id 17so588713gwj.31 for ; Thu, 25 Nov 2010 08:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nbLlyTNxuvnK+rqwqHhMSZa5F83WVK7ZOz2euQBQWxg=; b=YDxtvYNle+O2iP1J4GO4PwpYi8+IKZAUlARjzXcTB4TG57eegUCbikbCrMfXPSW6Ka TlGgXB2HmdbRrZcNg7OAOoMOs4Dw0U7+Ms3OcmqKXJZNeTaxS01M1VIz0Oood4F5qyBy /rhjWqHGUAJ0+A2Pc299avhmKl6lFqeQr/9/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Lic9OCJrgIR2Baf9aL74wXAJDyI6HHEB548cbRkjs3qnZtOMfp46ZrMRFjr7QQqK+D xCs4gT5rq1ZLC/+cyBGgLDikMrwco5ZKJL8qRaLilUmfCnNscxw6z3nffDIQzfSrZkK8 Ay8OUfqsKFMFgk5F8oBFUFtCTo46Ts3ZtZy+w= MIME-Version: 1.0 Received: by 10.42.224.136 with SMTP id io8mr285154icb.489.1290704173251; Thu, 25 Nov 2010 08:56:13 -0800 (PST) Received: by 10.42.222.2 with HTTP; Thu, 25 Nov 2010 08:56:13 -0800 (PST) In-Reply-To: References: Date: Thu, 25 Nov 2010 22:26:13 +0530 Message-ID: Subject: Query regarding Source IP check mentioned in RFC 5884 From: Kesavan To: rtg-bfd@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Thu, 25 Nov 2010 16:55:13 -0000 Hello draft authors Need clarification regarding Section 7 in RFC 5884 which mentions =A0=A0 =93This implies that an LSR MUST =A0=A0 ignore BFD packets for a given session, demultiplexed using the =A0=A0 received Your Discriminator field, if the session is in UP state and =A0=A0 if the My Discriminator or the Source IP address fields of the =A0=A0 received packet do not match the values associated with the session.= =94 A router receiving the BFD control packet over an LSP/tunnel could do the validation of the received source IP address against the source tunnel interface IP address maintained by it or the peer router=92s (BFD session peer from whom the packet is received) ip address. Is it required that the validation could be done against any of these addresses or has to be done against the tunnel interface IP only, to qualify it as a valid BFD pac= ket. Regards, Kesavan From mach@huawei.com Thu Nov 25 23: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 D1DB43A695C for ; Thu, 25 Nov 2010 23:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.244 X-Spam-Level: X-Spam-Status: No, score=-4.244 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_ABOUTYOU=0.5, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, 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 2C8+pE366llY for ; Thu, 25 Nov 2010 23:26:40 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BD9C53A6A0B for ; Thu, 25 Nov 2010 23:26:40 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LCH00BXXDZYSL@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Fri, 26 Nov 2010 15:26:22 +0800 (CST) Received: from m55527c ([10.110.98.66]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LCH00M8ODZXU3@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Fri, 26 Nov 2010 15:26:22 +0800 (CST) Date: Fri, 26 Nov 2010 15:26:21 +0800 From: Mach Chen Subject: Re: New Draft- BFD Express Path In-reply-to: To: Spencer Giacalone , rtg-bfd@ietf.org Message-id: <0BE27E3B7EDF454B86723D8ED71C4D6F@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=windows-1252; reply-type=original Content-transfer-encoding: 8BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: 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, 26 Nov 2010 07:26:41 -0000 Hi Spence, Some comments about your draft! Seems that the most concern of your network is the delay metric. You also mentioned in the draft that other measurements (jitter, loss) could be supported later, but based on the current definitions (fixed fields, no other flags for indication), seems that it is difficut to extend to support other measurements, so why not consider using TLV-based mechanisms hence to make it more extensible? Your draft proposes to use diag codes for indicating whether BFD express path function is enabled and/or the clock is synchronized to the same soure. >From the semantic of diag codes that are originaly designed for diagnotic purpose, I am not sure this is the right to go. By the way, why need to communicate whether clock is synchronized? IMHO, if someone wants to do one-way delay measurement, clock synchroniztion is the precondition, it should be done before the measurement. As for the auth compatible issue, in our previous draft, it proposed to use TLV-based mechanism. And the A(Authentication) bit is re-used to indicate the existing of the performance monitoring TLVs and/or the Authentication TLVs, and then subsequent processing are based on the actual types of the TLVs, so no changes will be made to the Authenctiaction relevant processing and it is compatible. So if we could change the semantic of the A bit, for example: the bit is used to indicate whether Optional sections exist, it will make BFD more extensible. Best regards, Mach -------------------------------------------------- From: "Spencer Giacalone" Sent: Tuesday, November 23, 2010 11:35 PM To: Subject: New Draft- BFD Express Path > Dear WG, > > A new draft, called �BFD Express Path� > (draft-giacalone-bfd-express-path-00) has been submitted for review. > The primary intent of this draft is to mitigate capability gaps and > exploit opportunities in certain performance sensitive networks. BFD > Express Path creates a scalable, flexible, and integrated framework > for gathering detailed network performance information. This > information could be used to influence routing or traffic engineering, > or for other network management purposes. It is assumed that further > drafts will provide routing protocol extensions. BFD Express Path is > focused on real world issues, and is aimed at (for example) the > production network that I am responsible for. I invite discussion, > comments, or questions. The abstract is as follows, and the draft > itself is posted on the WG page: > > �In certain networks, such as, but not limited to, financial > information networks (e.g. stock market data providers), network > performance criteria (e.g. latency) have become (or are becoming) as > (or more) critical to data path selection than other metrics. This > document describes extensions to the BFD protocol, such that > network performance information can be gathered in a scalable fashion, > and subsequently used (by other protocols) to make path selection > decisions. These extensions will also provide granular performance > monitoring information.� > > Regards, > > Spencer From dkatz@juniper.net Fri Nov 26 09:50:29 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 7514D3A6B26 for ; Fri, 26 Nov 2010 09:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 nNF+bjOizQXc for ; Fri, 26 Nov 2010 09:50:28 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 576463A6B25 for ; Fri, 26 Nov 2010 09:50:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTO/zop8FqNateUsdhXoVO6FjW8kTX6o5@postini.com; Fri, 26 Nov 2010 09:51:32 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 26 Nov 2010 09:48:35 -0800 Received: from [172.24.234.1] (dkatz-sslvpn-nc.jnpr.net [172.24.234.1]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id oAQHmZb67545; Fri, 26 Nov 2010 09:48:35 -0800 (PST) (envelope-from dkatz@juniper.net) Subject: Re: Query regarding Source IP check mentioned in RFC 5884 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="windows-1252" From: Dave Katz In-Reply-To: Date: Fri, 26 Nov 2010 11:48:34 -0600 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Kesavan X-Mailer: Apple Mail (2.1082) 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, 26 Nov 2010 17:50:29 -0000 The point is that, whatever IP addresses are used, they must not change = during the life of the session. This is not a matter of "validating" = the source address against some non-BFD content, but simply ensuring = that the *same* IP address is received in all subsequent BFD packets = after the first. The rules for choosing the first are elsewhere in the = document. --Dave On Nov 25, 2010, at 10:56 AM, Kesavan wrote: > Hello draft authors >=20 > Need clarification regarding Section 7 in RFC 5884 which mentions >=20 > =93This implies that an LSR MUST > ignore BFD packets for a given session, demultiplexed using the > received Your Discriminator field, if the session is in UP state = and > if the My Discriminator or the Source IP address fields of the > received packet do not match the values associated with the = session.=94 >=20 > A router receiving the BFD control packet over an LSP/tunnel could do > the validation of the > received source IP address against the source tunnel interface IP > address maintained by it or the peer router=92s (BFD session peer from > whom the packet is received) ip address. > Is it required that the validation could be done against any of these > addresses or has to be > done against the tunnel interface IP only, to qualify it as a valid = BFD packet. >=20 >=20 > Regards, > Kesavan >=20 >=20 From spencer.giacalone@gmail.com Sat Nov 27 18:47:53 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 E26973A6A92 for ; Sat, 27 Nov 2010 18:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_ABOUTYOU=0.5] 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 rFGlRwLPOYFI for ; Sat, 27 Nov 2010 18:47:52 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 322263A69A0 for ; Sat, 27 Nov 2010 18:47:52 -0800 (PST) Received: by iwn40 with SMTP id 40so4272258iwn.31 for ; Sat, 27 Nov 2010 18:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T7TfOyeuwzveH0xtyn6wXgYWBsTJMbIzn6YnkPQqHLk=; b=F7gUlmJhnLSTbJ03bA7ZFgr8WpvuyvWAogbWxCwHPebmJ5JntvDsPqS1Unsi/gb9Mx kBQ7qxD4K17y1TsKtfJVh3idUM4Xj2ghs5I1dKU7bYDv4a+oHIn4bzx2+Ekx7dNC8FeH l4okVJpS4s9eWkXfhvELhtXXJbgAC2fFgRkAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iLHTink8oIXVVfieHZ79NzrsSGC0FJ3Ess/LXmXDgyzxKMqpVmyycq9vUktwMUq7/Q /ScCfzVCccpDjkvOEeVS7x/brhBHXSHvPh34f5pFd2/7K0k+kWq5f4wj4YA7VTneIY9U AbgCTbJbXTOo+xOzu4oIdifIrzI0xd0/CP/5s= MIME-Version: 1.0 Received: by 10.231.16.136 with SMTP id o8mr3069799iba.43.1290912538520; Sat, 27 Nov 2010 18:48:58 -0800 (PST) Received: by 10.231.155.9 with HTTP; Sat, 27 Nov 2010 18:48:58 -0800 (PST) In-Reply-To: <0BE27E3B7EDF454B86723D8ED71C4D6F@m55527c> References: <0BE27E3B7EDF454B86723D8ED71C4D6F@m55527c> Date: Sat, 27 Nov 2010 21:48:58 -0500 Message-ID: Subject: Re: New Draft- BFD Express Path From: Spencer Giacalone To: Mach Chen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Sun, 28 Nov 2010 02:47:54 -0000 When using BFD Express Path in Echo mode or with the P bit set, it's important to know that the remote system's response timestamps are compatible with the ones being sent. We can do that with a bit setting (in the control packet or elsewhere- see TLV discussion below), or by making a sync protocol mandatory. I take it that you feel making it a precondition is the way to go (and therefore the sync bit is redundant). Is there further comment from the WG on whether it makes sense to make a sync protocol a precondition from an implementation standpoint? I agree that the use of TLVs is really the right way to go for extending BFD's functionality. Is there any opinion from the WG on whether it's easier to change the purpose of the A bit to indicate that generic TLVs follow, or whether it's easier to assign something like a diag code for this purpose? It seems like either one would do, and that it comes down to backwards compatibility. If most implementations ignore unexpected auth extension formats/types when the A bit is set, then that is a "cleaner" option from a protocol design standpoint. If not, and most implementations ignore unknown diag codes or unknown extension formats, then this should be easier to code and to deploy in production (no wholesale, "big-bang" network deployments required). There is no reason why Express Path cannot use TLVs. However, since TLVs have implications beyond Express Path, I think we should view them and Express Path as separate, but complimentary. Spence On Fri, Nov 26, 2010 at 2:26 AM, Mach Chen wrote: > Hi Spence, > > Some comments about your draft! > > Seems that the most concern of your network is the delay metric. You also > mentioned in the draft that other measurements (jitter, loss) could be > supported later, but based on the current definitions (fixed fields, no > other flags for indication), seems that it is difficut to extend to suppo= rt > other measurements, so why not consider using TLV-based mechanisms hence = to > make it more extensible? > > Your draft proposes to use diag codes for indicating whether BFD express > path function is enabled and/or the clock is synchronized to the same sou= re. > From the semantic of diag codes that are originaly designed for diagnotic > purpose, I am not sure this is the right to go. By the way, why need to > communicate whether clock is synchronized? IMHO, if someone wants to do > one-way delay measurement, clock synchroniztion is the precondition, it > should be done before the measurement. > > As for the auth compatible issue, in our previous draft, it proposed to u= se > TLV-based mechanism. And the A(Authentication) bit is re-used to indicate > the existing of the performance monitoring TLVs and/or the Authentication > TLVs, and then subsequent processing are based on the actual types of the > TLVs, so no changes will be made to the Authenctiaction relevant processi= ng > and it is compatible. So if we could change the semantic of the A bit, fo= r > example: the bit is used to indicate whether Optional sections exist, it > will make BFD more extensible. > > Best regards, > Mach > > -------------------------------------------------- > From: "Spencer Giacalone" > Sent: Tuesday, November 23, 2010 11:35 PM > To: > Subject: New Draft- BFD Express Path > >> Dear WG, >> >> A new draft, called =93BFD Express Path=94 >> (draft-giacalone-bfd-express-path-00) has been submitted for review. >> The primary intent of this draft is to mitigate capability gaps and >> exploit opportunities in certain performance sensitive networks. BFD >> Express Path creates a scalable, flexible, and integrated framework >> for gathering detailed network performance information. This >> information could be used to influence routing or traffic engineering, >> or for other network management purposes. It is assumed that further >> drafts will provide routing protocol extensions. BFD Express Path is >> focused on real world issues, and is aimed at (for example) the >> production network that I am responsible for. I invite discussion, >> comments, or questions. The abstract is as follows, and the draft >> itself is posted on the WG page: >> >> =93In certain networks, such as, but not limited to, financial >> information networks (e.g. stock market data providers), network >> performance criteria (e.g. latency) have become (or are becoming) as >> (or more) critical to data path selection than other metrics. This >> document describes extensions to the BFD protocol, such that >> network performance information can be gathered in a scalable fashion, >> and subsequently used (by other protocols) to make path selection >> decisions. These extensions will also provide granular performance >> monitoring information.=94 >> >> Regards, >> >> Spencer > > From dward@juniper.net Sun Nov 28 08:22:16 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 34E5428B23E for ; Sun, 28 Nov 2010 08:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 a9X-8dog+NOD for ; Sun, 28 Nov 2010 08:22:15 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 380B428C102 for ; Sun, 28 Nov 2010 08:22:15 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTPKB+fSTSTlDWLbMrWOaoDyoETuvekPh@postini.com; Sun, 28 Nov 2010 08:23:23 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Sun, 28 Nov 2010 08:19:30 -0800 From: David Ward To: Spencer Giacalone Date: Sun, 28 Nov 2010 08:19:29 -0800 Subject: Re: New Draft- BFD Express Path Thread-Topic: New Draft- BFD Express Path Thread-Index: AcuPGAjVai/eKSDKRDueDyaHeWg0Bw== Message-ID: <29512381-0E0D-4793-A29E-B9A147AF876D@juniper.net> References: <0BE27E3B7EDF454B86723D8ED71C4D6F@m55527c> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" , David Ward 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: Sun, 28 Nov 2010 16:22:16 -0000 Spencer - You'd want to use the "A" bit to state that TLVs follow. If one is not pass= ing auth information you'd have to carry some extra bits but, the A bit is = the way to do it not in a diag code. -DWard On Nov 27, 2010, at 6:48 PM, Spencer Giacalone wrote: > When using BFD Express Path in Echo mode or with the P bit set, it's > important to know that the remote system's response timestamps are > compatible with the ones being sent. We can do that with a bit setting > (in the control packet or elsewhere- see TLV discussion below), or by > making a sync protocol mandatory. I take it that you feel making it a > precondition is the way to go (and therefore the sync bit is > redundant). Is there further comment from the WG on whether it makes > sense to make a sync protocol a precondition from an implementation > standpoint? >=20 > I agree that the use of TLVs is really the right way to go for > extending BFD's functionality. Is there any opinion from the WG on > whether it's easier to change the purpose of the A bit to indicate > that generic TLVs follow, or whether it's easier to assign something > like a diag code for this purpose? It seems like either one would do, > and that it comes down to backwards compatibility. If most > implementations ignore unexpected auth extension formats/types when > the A bit is set, then that is a "cleaner" option from a protocol > design standpoint. If not, and most implementations ignore unknown > diag codes or unknown extension formats, then this should be easier to > code and to deploy in production (no wholesale, "big-bang" network > deployments required). >=20 > There is no reason why Express Path cannot use TLVs. However, since > TLVs have implications beyond Express Path, I think we should view > them and Express Path as separate, but complimentary. >=20 > Spence >=20 From dkatz@juniper.net Mon Nov 29 12:10:30 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 28CAA28C108 for ; Mon, 29 Nov 2010 12:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 bv03floDeBug for ; Mon, 29 Nov 2010 12:10:28 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id C851B28C0F5 for ; Mon, 29 Nov 2010 12:10:28 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTPQI7o5DCBdKZE25eoszza6YYiXvM65r@postini.com; Mon, 29 Nov 2010 12:11:39 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 29 Nov 2010 12:10:26 -0800 Received: from daves-laptop.jnpr.net (daves-laptop.jnpr.net [172.17.23.227]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id oATKALb68353; Mon, 29 Nov 2010 12:10:21 -0800 (PST) (envelope-from dkatz@juniper.net) Subject: Re: New Draft- BFD Express Path MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="windows-1252" From: Dave Katz In-Reply-To: