From mukund.mani@gmail.com Tue Oct 5 06:36:28 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 98EAD3A6B41 for ; Tue, 5 Oct 2010 06:36:28 -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 mDq0qlF5OAC6 for ; Tue, 5 Oct 2010 06:36:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 5C96F3A6F80 for ; Tue, 5 Oct 2010 06:36:17 -0700 (PDT) Received: by yxl31 with SMTP id 31so2482861yxl.31 for ; Tue, 05 Oct 2010 06:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4Dor33OTStlPhBaTm0m6oMFf8GaMjH+pdC4TkuVj1F4=; b=JirfdD53/SN7HiGVag8LN08hm+sJ+dc79ZbnZCWXDpKjJRLqrqNUkb74YLYxMKirVV FpGJqTnpTILnb5ftOdS+AYbSHX8HSisDYw7EMCZAIBU7ghahezXu3kXdxKyznltX/qig Vb2xPthkhsOYGqDskXRAFstcZZ/OPyrj9mTes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oTvGO6BwMGPMF8RLA6eHL4qilyLFUKol4qDz7dwsnV56dUP7XGLuLasE2a9bsQDhTi aihw/VmvsP881jZEICuXA5R23+98pWPyPNb5EhrH+KsGCh5hv+0zbiKkWVf58lcEfB5O GIg8XT0vi1ce+oB4iquTmvWnZekiGwjQwnalg= MIME-Version: 1.0 Received: by 10.151.18.10 with SMTP id v10mr129464ybi.217.1286285833972; Tue, 05 Oct 2010 06:37:13 -0700 (PDT) Received: by 10.42.3.3 with HTTP; Tue, 5 Oct 2010 06:37:13 -0700 (PDT) Date: Tue, 5 Oct 2010 19:07:13 +0530 Message-ID: Subject: Question regarding BFD MIB "draft-ietf-bfd-mib-10" From: Mukund Mani To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=000e0cd4a6dc36ac4c0491dec223 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, 05 Oct 2010 13:36:28 -0000 --000e0cd4a6dc36ac4c0491dec223 Content-Type: text/plain; charset=ISO-8859-1 Hi Could the MIB authors please clarify the following: The RowStatus description in the MIB states that when the row is in Active state no objects in the row can be modified except the bfdSessRowStatus and bfdSessStorageType. BFD base draft specifies the Poll Sequence mechanism to handle parameter changes (Tx,Rx intervals and Detect mult) without session state change. 6.8.2. Timer Negotiation The time values used to determine BFD packet transmission intervals and the session Detection Time are continuously negotiated, and thus may be changed at any time. 6.8.3. Timer Manipulation The time values used to determine BFD packet transmission intervals and the session Detection Time may be modified at any time without affecting the state of the session. My question thus is on the exact interpretation of RowStatus. If we go by MIB description, parameter change (Tx,Rx,Detect Mult) will not be allowed. Thus to change parameter do we then change the RowStatus to Not In Service ? This should not be the case since ideally on moving to Not In Service it is not correct to keep the remote BFD session parameters. And even if we do move to Not In Service, moving from Not In Service to Active thereon should ideally result in bootstrapping again. Correlating with the MIB how will then the Poll Sequence mechanism be realised (sending packets with P bits without affecting session state) With Regards Mukund --000e0cd4a6dc36ac4c0491dec223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
=A0
Could the MIB authors please clarify the following:
=A0
The RowStatus description in the MIB states that when the row is in Ac= tive state no objects in the row can be modified except
the bfdSessRowStatus and bfdSessStorageType.
=A0
BFD base draft specifies the Poll Sequence mechanism to handle paramet= er changes (Tx,Rx intervals and Detect mult)=A0without session state change= .
=A0
6.8.2.=A0 Timer Negotiation
=A0=A0 The time values used to determine BFD packet transmission inter= vals
=A0=A0 and the session Detection Time are continuously negotiated, = and thus
=A0=A0 may be changed at any time.
=A0

6.8.3.=A0 Timer Manipulation
=A0=A0 The time values used to determine BFD packet transmission inter= vals
=A0=A0 and the session Detection Time may be modified at any time w= ithout
=A0=A0 affecting the state of the session.
=A0
=A0
My question thus is on the exact interpretation of RowStatus.=A0 If we= go by MIB description, parameter change (Tx,Rx,Detect Mult)=A0will not be = allowed. Thus to change parameter do we then change the RowStatus to Not In= Service ?
This should not be the case since ideally on moving to Not In Service = it is not correct to keep the remote BFD session
parameters. And even if we do move to Not In Service, moving from Not = In Service to Active thereon=A0should ideally result in bootstrapping again= .
=A0
Correlating with the MIB how will then the=A0Poll Sequence mechanism b= e realised (sending packets with P bits without affecting session state)
=A0
With Regards
Mukund
--000e0cd4a6dc36ac4c0491dec223-- From mukund.mani@gmail.com Tue Oct 5 06:38:58 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A208C3A6C24; Tue, 5 Oct 2010 06:38:58 -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 CpZlajgBlL0U; Tue, 5 Oct 2010 06:38:56 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DC2CA3A6F51; Tue, 5 Oct 2010 06:38:54 -0700 (PDT) Received: by gyg10 with SMTP id 10so217521gyg.31 for ; Tue, 05 Oct 2010 06:39:52 -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:content-type; bh=SnTbwSOO1ydApZogd8e7NmWbRlu+weuy/cn7dpr6ahE=; b=KzrYC01wYFg0RVfWOkltNTC+vlaqgfvNbIrm+pgApeXM8LYom1KO8pF/oRecKSp6wb OZoGm8/KZqHxasGR+2U714yt0SltsnsTnrrdV7a3XXEox2/qiNz45NsjPJ52AjfbV63C GLx06kq+e8qZPvNAf9L1knLW3MmsUUEIp9nUA= 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; b=p1Mk3sMyeu1TLa7CNctlxiBPr4hEO8a675juy9qC1h2+yKgxMFNOsIcww+huu0d46O BAMzrcREdsyYnhkBFFV6UkyxsGaxvp3w2GUyrq/1jzx3efj5dOmTCKB+GR+JAd0uhA4w XPeu+eCS5whZBlFq8tFiuAS8KOByzxy0OYuok= MIME-Version: 1.0 Received: by 10.236.108.18 with SMTP id p18mr3729514yhg.58.1286285992367; Tue, 05 Oct 2010 06:39:52 -0700 (PDT) Received: by 10.42.3.3 with HTTP; Tue, 5 Oct 2010 06:39:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Oct 2010 19:09:52 +0530 Message-ID: Subject: Re: Regarding BFD Code Points for ACH header and MEP TLV for PW From: Mukund Mani To: mpls-tp@ietf.org, rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=90e6ba4fbe5ca795650491decb96 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, 05 Oct 2010 13:38:58 -0000 --90e6ba4fbe5ca795650491decb96 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 about > 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 payload > 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 > --90e6ba4fbe5ca795650491decb96 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
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@gma= il.com> wrote:

Hello group

=A0

=A0

  1. 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

  1. 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


--90e6ba4fbe5ca795650491decb96-- From Adrian.Farrel@huawei.com Tue Oct 5 06:59: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 CDE453A6F82 for ; Tue, 5 Oct 2010 06:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, 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 dPHjElbFGbyC for ; Tue, 5 Oct 2010 06:59:31 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id CDF413A6F75 for ; Tue, 5 Oct 2010 06:59:31 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9T003RYLKSLE@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Tue, 05 Oct 2010 07:00:29 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9T008GGLKR22@usaga01-in.huawei.com> for rtg-bfd@ietf.org; Tue, 05 Oct 2010 07:00:28 -0700 (PDT) Date: Tue, 05 Oct 2010 15:00:13 +0100 From: Adrian Farrel Subject: Tellabs BFD IPR Disclosures To: rtg-bfd@ietf.org Message-id: <0494D4252FFD410885EAD4E7439CD91D@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 13:59:32 -0000 Hi, The IESG has been probing to find out a little bit more about the recent IPR disclosures. Tellabs IP Counsel, Jae Kim, recently sent us this email: > As far as I know, the RFCs identified in Tellabs' recent disclosure, as > well as RFC 5880 (note that Tellabs plans to amend its recent > disclosure to include RFC 5880), do not expressly describe the > particular technology to which the present claims of the issued patents > and pending applications identified by Tellabs are directed. However, > Tellabs provides its disclosure to the extent that one or more patent > claims nevertheless may be necessary to technologies one may adopt > to implement one or more of such RFCs. > > In any event, given that the claims of a patent define the scope of the > invention, I encourage you to refer to the patent claims themselves to > the extent that you might seek any further insight on this matter. He also said: > In making this particular disclosure, Tellabs has not stated that the > disclosed > IPR necessarily covers every possible compliant implementation of IETF > RFCs 5881-84. Rather, Tellabs provides the disclosure to the extent that > the > disclosed IPR may be necessary for at least some compliant > implementations. You can see the disclosure at https://datatracker.ietf.org/ipr/1403/ You, your technical experts, and your legal counsels will need to make your own minds up about this and the apparent lateness of the disclosure. Thanks, Adrian From santoshpk@juniper.net Wed Oct 27 08:12:50 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 BD66F3A6961 for ; Wed, 27 Oct 2010 08:12:50 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCmQeOZGuqif for ; Wed, 27 Oct 2010 08:12:42 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 93BCE3A6A03 for ; Wed, 27 Oct 2010 08:12:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTMhBxzSiaN8GxjxYNBNLKysaPosNV/8F@postini.com; Wed, 27 Oct 2010 08:14:17 PDT Received: from p-emfe01-bng.jnpr.net (10.211.204.19) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Oct 2010 08:10:45 -0700 Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe01-bng.jnpr.net ([::1]) with mapi; Wed, 27 Oct 2010 20:40:43 +0530 From: Santosh P K To: "apvelan@cisco.com" Date: Wed, 27 Oct 2010 20:40:42 +0530 Subject: draft-palanivelan-bfd-v2-gr-08 Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act16R878vL0wuexT5a1DPZtS7wjiA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FB649DA20153634794BEBBAB504DA1AD4506130D74EMBX02BNGjnpr_" MIME-Version: 1.0 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, 27 Oct 2010 15:12:51 -0000 --_000_FB649DA20153634794BEBBAB504DA1AD4506130D74EMBX02BNGjnpr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Palanivelan, I have couple of doubts on this draft. Under section 6.2. Remote Neigh= bor Restart and Recovery, it's mentioned that. "When the set of systems had their BFD sessions established, with GR support as described in this document, when the remote neighbor restarts it will set the BFD diagnostics field to a value of 9 (Neighbor Restarting) in the control packet to its neighbor (local system)." This draft is trying to address the unplanned restart of protocols using = BFD, as the planned outage is handled today anyway. 1. How BFD would determine that protocol using BFD has gone for graceful= restart (in case of unplanned outage), to send BFD packet with BFD diagnos= tics field set to 9? 2. If BFD can determine that protocol using BFD has restarted with GR en= abled and that's not planned outage then can't we increase BFD session time= rs instead of having MyRestartInterval and yourRestartInterval fields? 3. In case we miss out initial couple of BFD packets with diagnostics fi= eld set to 9 due to BFD not having enough CPU slice on restarting router, t= hen at local router (helper) are we not bringing down the session? .................................... Thanks and regards Santosh P K --_000_FB649DA20153634794BEBBAB504DA1AD4506130D74EMBX02BNGjnpr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hello Palanivelan,
  =
   I have couple of doubts on this draft. Under section 6.2. Remo=
te Neighbor Restart and Recovery, it’s mentioned that.
 <=
/o:p>
  =
 “When the set of systems had their BFD sessions established, with GR=

  =
 support as described in this document, when the remote neighbor=

   =
;restarts it will set the BFD diagnostics field to a value of 9<=
/span>
  =
 (Neighbor Restarting) in the control packet to its neighbor (local
  =
 system).”
 <=
/o:p>
  This =
draft is trying to address the unplanned restart of protocols using BFD, as=
 the planned outage is handled today anyway. 
 <=
/o:p>
1.    How BFD would determine that protocol using BFD=
 has gone for graceful restart (in case of unplanned outage), to send BFD p=
acket with BFD diagnostics field set to 9?  
2.    If BFD can determine that protocol using BFD ha=
s restarted with GR enabled and that’s not planned outage then can=
217;t we increase BFD session timers instead of having MyRestartInterval an=
d yourRestartInterval fields?
3.    In case we miss out initial couple of BFD packe=
ts with diagnostics field set to 9 due to BFD not having enough CPU slice o=
n restarting router, then at local router (helper) are we not bringing down=
 the session? 



 



....................................<=
/o:p>



Thanks and regards

Santosh P K 



 



 
--_000_FB649DA20153634794BEBBAB504DA1AD4506130D74EMBX02BNGjnpr_-- From dkatz@juniper.net Wed Oct 27 10:18: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 A41683A69FF for ; Wed, 27 Oct 2010 10:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLP-d2tViI2E for ; Wed, 27 Oct 2010 10:18:23 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id A2C4B3A6A3B for ; Wed, 27 Oct 2010 10:18:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTMhfRxxNXSfJOJ4tEQAEFlDiFrPQQy8P@postini.com; Wed, 27 Oct 2010 10:20:10 PDT 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; Wed, 27 Oct 2010 10:18:51 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o9RHIob28027; Wed, 27 Oct 2010 10:18:50 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: draft-palanivelan-bfd-v2-gr-08 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary="Apple-Mail-11-655084661" From: Dave Katz In-Reply-To: Date: Wed, 27 Oct 2010 11:18:49 -0600 Message-ID: References: To: X-Mailer: Apple Mail (2.1081) Cc: Santosh P K , 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, 27 Oct 2010 17:18:26 -0000 --Apple-Mail-11-655084661 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" I somehow seem to have missed the ongoing revision of this draft. To underscore what Santosh says, I believe that GR interactions can be = dealt with in an informational BCP, without any modification of the base = spec. RFC 5882 has a bunch of verbiage to try to address exactly this = scenario. But to the details: I don't see how there is *any* mechanism that can deal with unplanned = restart if the BFD session can't stay up long enough for the restarting = system to start sending BFD packets again. The non-restarting system = fundamentally cannot differentiate between this and a crashed neighbor; = it must assume that the path has failed and do whatever it needs to = (take down a routing protocol adjacency, for example.) Unless I'm = missing something, this is an unavoidable side effect of fast failure = detection, and the only way to deal with it is to make the behavior of = the dependent control protocol implementations less onerous when the = topology changes (which is frankly what folks should have done instead = of inventing GR, which in my opinion is an awful kludge). If the BFD session can stay up long enough for the restarting system to = send BFD packets again, and the control protocol has GR capabilities, = the second paragraph of section 3.3 of RFC 5882 describes in general = terms what to do. In particular, the mythical adaptation layer = described in the RFC can detect the fact that the session is actively = being reestablished (by virtue of the receipt of BFD packets from the = restarting system) and apply hysteresis to the BFD session flap. This = will give the restarted control protocol sufficient time to signal the = GR and avoid perturbation in that layer. The Diag field is intended to be *informational* only, that is, a = write-only field as far as the BFD state machine is concerned. There is = currently *no* place in the spec where a receiving system uses this = field as part of the BFD state machine. Using it to signal within the = protocol is outside of the architectural thinking (which, admittedly, is = not explicitly documented). But beyond that, the Diag field is = "fragile" within the protocol; it is easily overwritten under various = conditions based on the existing spec, and attempting to preserve its = value for signaling would require constraining the operation of the = sender. This is hinted at in section 6.8.17 in RFC 5880 when describing = concatenated paths, for example. I see no value in signaling the GR timers in the protocol; if a = restarting system can trigger this mechanism by sending Diag 9, it could = also do so by simply cranking up the transmit and receive intervals to = whatever values it desires. For planned restart, this is all that is = necessary (and this can be done cleanly at that time.) For unplanned = restart, at some level it doesn't matter; by the time you can signal = anything from the restarted system, you can run BFD at full speed, or = whatever rate you would like to signal at that time. All the stuff about broadband and large fan-out seems to be beside the = point, an excuse for poor system design, and doesn't seem to add = anything to the argument. A system that is fielding DHCP requests but = is ignoring fundamental connectivity is broken in any case (and as = Santosh points out, no mechanism in the protocol is going to help you if = the packets can't be sent and received anyhow.) Doing successful = unplanned GR has certain requirements, among them ensuring that the = protocols involved can actually talk, and the particular example is not = a particularly good one, IMHO. What am I missing? --Dave On Oct 27, 2010, at 9:10 AM, Santosh P K wrote: > Hello Palanivelan, > I have couple of doubts on this draft. Under section 6.2. Remote = Neighbor Restart and Recovery, it=92s mentioned that. > =20 > =93When the set of systems had their BFD sessions established, with = GR > support as described in this document, when the remote neighbor > restarts it will set the BFD diagnostics field to a value of 9 > (Neighbor Restarting) in the control packet to its neighbor (local > system).=94 > =20 > This draft is trying to address the unplanned restart of protocols = using BFD, as the planned outage is handled today anyway.=20 > =20 > 1. How BFD would determine that protocol using BFD has gone for = graceful restart (in case of unplanned outage), to send BFD packet with = BFD diagnostics field set to 9? =20 > 2. If BFD can determine that protocol using BFD has restarted with = GR enabled and that=92s not planned outage then can=92t we increase BFD = session timers instead of having MyRestartInterval and = yourRestartInterval fields? > 3. In case we miss out initial couple of BFD packets with = diagnostics field set to 9 due to BFD not having enough CPU slice on = restarting router, then at local router (helper) are we not bringing = down the session?=20 > =20 > .................................... > Thanks and regards > Santosh P K >=20 > =20 >=20 > =20 --Apple-Mail-11-655084661 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" I = somehow seem to have missed the ongoing revision of this = draft.

To underscore what Santosh says, I believe = that GR interactions can be dealt with in an informational BCP, without = any modification of the base spec.  RFC 5882 has a bunch of = verbiage to try to address exactly this = scenario.


But to the = details:

I don't see how there is *any* = mechanism that can deal with unplanned restart if the BFD session can't = stay up long enough for the restarting system to start sending BFD = packets again.  The non-restarting system fundamentally cannot = differentiate between this and a crashed neighbor;  it must assume = that the path has failed and do whatever it needs to (take down a = routing protocol adjacency, for example.)  Unless I'm missing = something, this is an unavoidable side effect of fast failure detection, = and the only way to deal with it is to make the behavior of the = dependent control protocol implementations less onerous when the = topology changes (which is frankly what folks should have done instead = of inventing GR, which in my opinion is an awful = kludge).

If the BFD session can stay up long = enough for the restarting system to send BFD packets again, and the = control protocol has GR capabilities, the second paragraph of section = 3.3 of RFC 5882 describes in general terms what to do.  In = particular, the mythical adaptation layer described in the RFC can = detect the fact that the session is actively being reestablished (by = virtue of the receipt of BFD packets from the restarting system) and = apply hysteresis to the BFD session flap.  This will give the = restarted control protocol sufficient time to signal the GR and avoid = perturbation in that layer.

The Diag field is = intended to be *informational* only, that is, a write-only field as far = as the BFD state machine is concerned.  There is currently *no* = place in the spec where a receiving system uses this field as part of = the BFD state machine.  Using it to signal within the protocol is = outside of the architectural thinking (which, admittedly, is not = explicitly documented).  But beyond that, the Diag field is = "fragile" within the protocol;  it is easily overwritten under = various conditions based on the existing spec, and attempting to = preserve its value for signaling would require constraining the = operation of the sender.  This is hinted at in section 6.8.17 in = RFC 5880 when describing concatenated paths, for = example.

I see no value in signaling the GR = timers in the protocol;  if a restarting system can trigger this = mechanism by sending Diag 9, it could also do so by simply cranking up = the transmit and receive intervals to whatever values it desires. =  For planned restart, this is all that is necessary (and this can = be done cleanly at that time.)  For unplanned restart, at some = level it doesn't matter;  by the time you can signal anything from = the restarted system, you can run BFD at full speed, or whatever rate = you would like to signal at that time.

All the = stuff about broadband and large fan-out seems to be beside the point, an = excuse for poor system design, and doesn't seem to add anything to the = argument.  A system that is fielding DHCP requests but is ignoring = fundamental connectivity is broken in any case (and as Santosh points = out, no mechanism in the protocol is going to help you if the packets = can't be sent and received anyhow.)  Doing successful unplanned GR = has certain requirements, among them ensuring that the protocols = involved can actually talk, and the particular example is not a = particularly good one, IMHO.

What am I = missing?

--Dave


On Oct 27, 2010, at 9:10 AM, Santosh P K = wrote:

Hello =
Palanivelan,
   =93When the set of =
systems had their BFD sessions established, with =
GR
   support as described =
in this document, when the remote =
neighbor
   restarts it will set =
the BFD diagnostics field to a value of =
9
   (Neighbor =
Restarting) in the control packet to its neighbor =
(local
   =
system).=94
  This draft is trying to =
address the unplanned restart of protocols using BFD, as the planned =
outage is handled today anyway. 
    =
How BFD would determine that protocol =
using BFD has gone for graceful restart (in case of unplanned outage), =
to send BFD packet with BFD diagnostics field set to 9? =
 
2.    =
If BFD can determine that protocol =
using BFD has restarted with GR enabled and that=92s not planned outage =
then can=92t we increase BFD session timers instead of having =
MyRestartInterval and yourRestartInterval fields?
3.    In case =
we miss out initial couple of BFD packets with diagnostics field set to =
9 due to BFD not having enough CPU slice on restarting router, then at =
local router (helper) are we not bringing down the session? =
Thanks and regards
Santosh P K

In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act1+z53M/ERDyqFT9WzBPdIyTkFFgARBhBA References: From: "Palanivelan A (apvelan)" To: "Dave Katz" X-OriginalArrivalTime: 28 Oct 2010 13:01:36.0704 (UTC) FILETIME=[40F82400:01CB76A0] 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: Thu, 28 Oct 2010 12:59:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB76A0.40C4250A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 We see BFD to be serving what it is meant to and the wide implementations of this technology points to its acceptance.=20 If we have to pick at the areas that are little grey, BFD for routing protocols with GR comes as one of them. =20 Though the success of BFd with GR depend on the system design and that there can be different ways of addressing the issue in line with the design,=20 This draft intended to provide a common solution that can be adopted. This was originally intended for "standards track". =20 But this working group, within its rights felt that BFD would not look for such an extension and that this need not be considered for a standards track and=20 I am certainly not debating on that. The independent reviewers however proposed that this draft can be recorded for future and hence were willing to consider this draft for a "Historic" status.The revisions to this draft were all based on these review comments. =20 I hope this clarifies the intend of the draft and also the status of this draft as on date.=20 =20 I guess, for someone who is facing this issue and looking at a solution, this draft gives an option (not the only one though) to address and that is my bottom point. =20 Thanks and Regards, A.Palanivelan =20 From: Dave Katz [mailto:dkatz@juniper.net]=20 Sent: Wednesday, October 27, 2010 10:49 PM To: Palanivelan A (apvelan) Cc: rtg-bfd WG; Santosh P K Subject: Re: draft-palanivelan-bfd-v2-gr-08 =20 I somehow seem to have missed the ongoing revision of this draft. =20 To underscore what Santosh says, I believe that GR interactions can be dealt with in an informational BCP, without any modification of the base spec. RFC 5882 has a bunch of verbiage to try to address exactly this scenario. =20 =20 But to the details: =20 I don't see how there is *any* mechanism that can deal with unplanned restart if the BFD session can't stay up long enough for the restarting system to start sending BFD packets again. The non-restarting system fundamentally cannot differentiate between this and a crashed neighbor; it must assume that the path has failed and do whatever it needs to (take down a routing protocol adjacency, for example.) Unless I'm missing something, this is an unavoidable side effect of fast failure detection, and the only way to deal with it is to make the behavior of the dependent control protocol implementations less onerous when the topology changes (which is frankly what folks should have done instead of inventing GR, which in my opinion is an awful kludge). =20 If the BFD session can stay up long enough for the restarting system to send BFD packets again, and the control protocol has GR capabilities, the second paragraph of section 3.3 of RFC 5882 describes in general terms what to do. In particular, the mythical adaptation layer described in the RFC can detect the fact that the session is actively being reestablished (by virtue of the receipt of BFD packets from the restarting system) and apply hysteresis to the BFD session flap. This will give the restarted control protocol sufficient time to signal the GR and avoid perturbation in that layer. =20 The Diag field is intended to be *informational* only, that is, a write-only field as far as the BFD state machine is concerned. There is currently *no* place in the spec where a receiving system uses this field as part of the BFD state machine. Using it to signal within the protocol is outside of the architectural thinking (which, admittedly, is not explicitly documented). But beyond that, the Diag field is "fragile" within the protocol; it is easily overwritten under various conditions based on the existing spec, and attempting to preserve its value for signaling would require constraining the operation of the sender. This is hinted at in section 6.8.17 in RFC 5880 when describing concatenated paths, for example. =20 I see no value in signaling the GR timers in the protocol; if a restarting system can trigger this mechanism by sending Diag 9, it could also do so by simply cranking up the transmit and receive intervals to whatever values it desires. For planned restart, this is all that is necessary (and this can be done cleanly at that time.) For unplanned restart, at some level it doesn't matter; by the time you can signal anything from the restarted system, you can run BFD at full speed, or whatever rate you would like to signal at that time. =20 All the stuff about broadband and large fan-out seems to be beside the point, an excuse for poor system design, and doesn't seem to add anything to the argument. A system that is fielding DHCP requests but is ignoring fundamental connectivity is broken in any case (and as Santosh points out, no mechanism in the protocol is going to help you if the packets can't be sent and received anyhow.) Doing successful unplanned GR has certain requirements, among them ensuring that the protocols involved can actually talk, and the particular example is not a particularly good one, IMHO. =20 What am I missing? =20 --Dave =20 =20 On Oct 27, 2010, at 9:10 AM, Santosh P K wrote: Hello Palanivelan, I have couple of doubts on this draft. Under section 6.2. Remote Neighbor Restart and Recovery, it's mentioned that. =20 "When the set of systems had their BFD sessions established, with GR support as described in this document, when the remote neighbor restarts it will set the BFD diagnostics field to a value of 9 (Neighbor Restarting) in the control packet to its neighbor (local system)." =20 This draft is trying to address the unplanned restart of protocols using BFD, as the planned outage is handled today anyway.=20 =20 1. How BFD would determine that protocol using BFD has gone for graceful restart (in case of unplanned outage), to send BFD packet with BFD diagnostics field set to 9? =20 2. If BFD can determine that protocol using BFD has restarted with GR enabled and that's not planned outage then can't we increase BFD session timers instead of having MyRestartInterval and yourRestartInterval fields? 3. In case we miss out initial couple of BFD packets with diagnostics field set to 9 due to BFD not having enough CPU slice on restarting router, then at local router (helper) are we not bringing down the session?=20 =20 .................................... Thanks and regards Santosh P K =20 =20 =20 ------_=_NextPart_001_01CB76A0.40C4250A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

We see BFD to be serving what it is meant to and the wide implementations of this technology points to its acceptance. =

If we have to pick at the areas that are little grey, BFD = for routing protocols with GR comes as one of them.

 

Though the success of BFd with GR depend on the system = design and that there can be different ways of addressing the issue in line = with the design,

This draft intended to provide a common solution that can = be adopted. This was originally intended for “standards = track”.

 

But this working group, within its rights felt that BFD = would not look for such an extension and that this need not be considered for = a standards track and

I am certainly not debating on that. The independent = reviewers however proposed that this draft can be recorded for future and hence = were willing to

consider this draft for  a “Historic” = status.The revisions to this draft were all based on these review = comments.

 

I hope this clarifies the intend of the draft and also = the status of this draft as on date.

 

I guess, for someone who is facing this issue and looking =  at a solution, this draft gives an option (not the only one though) =  to address and that is my bottom point.

 

Thanks and Regards,

A.Palanivelan

 

From:= Dave Katz [mailto:dkatz@juniper.net]
Sent: Wednesday, October 27, 2010 10:49 PM
To: Palanivelan A (apvelan)
Cc: rtg-bfd WG; Santosh P K
Subject: Re: draft-palanivelan-bfd-v2-gr-08

 

I somehow seem to have missed the ongoing revision = of this draft.

 

To underscore what Santosh says, I believe that GR interactions can be dealt with in an informational BCP, without any modification of the base spec.  RFC 5882 has a bunch of verbiage to = try to address exactly this scenario.

 

 

But to the details:

 

I don't see how there is *any* mechanism that can = deal with unplanned restart if the BFD session can't stay up long enough for the restarting system to start sending BFD packets again.  The = non-restarting system fundamentally cannot differentiate between this and a crashed = neighbor;  it must assume that the path has failed and do whatever it needs = to (take down a routing protocol adjacency, for example.)  Unless I'm = missing something, this is an unavoidable side effect of fast failure detection, = and the only way to deal with it is to make the behavior of the dependent = control protocol implementations less onerous when the topology changes (which = is frankly what folks should have done instead of inventing GR, which in my opinion is an awful kludge).

 

If the BFD session can stay up long enough for the restarting system to send BFD packets again, and the control protocol = has GR capabilities, the second paragraph of section 3.3 of RFC 5882 describes = in general terms what to do.  In particular, the mythical adaptation = layer described in the RFC can detect the fact that the session is actively = being reestablished (by virtue of the receipt of BFD packets from the = restarting system) and apply hysteresis to the BFD session flap.  This will = give the restarted control protocol sufficient time to signal the GR and avoid perturbation in that layer.

 

The Diag field is intended to be *informational* = only, that is, a write-only field as far as the BFD state machine is concerned.  There is currently *no* place in the spec where a receiving system = uses this field as part of the BFD state machine.  Using it to signal = within the protocol is outside of the architectural thinking (which, = admittedly, is not explicitly documented).  But beyond that, the Diag field is "fragile" within the protocol;  it is easily overwritten = under various conditions based on the existing spec, and attempting to = preserve its value for signaling would require constraining the operation of the = sender.  This is hinted at in section 6.8.17 in RFC 5880 when describing = concatenated paths, for example.

 

I see no value in signaling the GR timers in the = protocol;  if a restarting system can trigger this mechanism by sending Diag = 9, it could also do so by simply cranking up the transmit and receive = intervals to whatever values it desires.  For planned restart, this is all that = is necessary (and this can be done cleanly at that time.)  For = unplanned restart, at some level it doesn't matter;  by the time you can = signal anything from the restarted system, you can run BFD at full speed, or = whatever rate you would like to signal at that time.

 

All the stuff about broadband and large fan-out = seems to be beside the point, an excuse for poor system design, and doesn't seem to = add anything to the argument.  A system that is fielding DHCP requests = but is ignoring fundamental connectivity is broken in any case (and as Santosh = points out, no mechanism in the protocol is going to help you if the packets = can't be sent and received anyhow.)  Doing successful unplanned GR has = certain requirements, among them ensuring that the protocols involved can = actually talk, and the particular example is not a particularly good one, = IMHO.

 

What am I missing?

 

--Dave

 

 

On Oct 27, 2010, at 9:10 AM, Santosh P K = wrote:



Hello Palanivelan,
    =
 I have couple of doubts on this draft. Under section 6.2. Remote =
Neighbor Restart and Recovery, it’s mentioned =
that.
 
   =
“When the set of systems had their BFD sessions established, with =
GR
   support as described in this =
document, when the remote neighbor
  =
 restarts it will set the BFD diagnostics field to a value of =
9
   (Neighbor Restarting) in the control =
packet to its neighbor (local
   =
system).”
 
  =
This draft is trying to address the unplanned restart of protocols using =
BFD, as the planned outage is handled today anyway. =

 
1.    How BFD =
would determine that protocol using BFD has gone for graceful restart =
(in case of unplanned outage), to send BFD packet with BFD diagnostics =
field set to 9?  
2.    If BFD =
can determine that protocol using BFD has restarted with GR enabled and =
that’s not planned outage then can’t we increase BFD session =
timers instead of having MyRestartInterval and yourRestartInterval =
fields?
3.    In case =
we miss out initial couple of BFD packets with diagnostics field set to =
9 due to BFD not having enough CPU slice on restarting router, then at =
local router (helper) are we not bringing down the session? =

 =

.............= .......................

Thanks and regards
Santosh P K

 

 

 

------_=_NextPart_001_01CB76A0.40C4250A-- From dkatz@juniper.net Thu Oct 28 10:10: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 14FB83A695C for ; Thu, 28 Oct 2010 10:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUGPfVND9W6y for ; Thu, 28 Oct 2010 10:10:33 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 728BD3A67F2 for ; Thu, 28 Oct 2010 10:10:33 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTMmu+bzXOvmeIq49Fh75ea4oQoiVo+13@postini.com; Thu, 28 Oct 2010 10:12:26 PDT 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; Thu, 28 Oct 2010 10:11:17 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o9SHBGb76810; Thu, 28 Oct 2010 10:11:16 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: draft-palanivelan-bfd-v2-gr-08 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary="Apple-Mail-21-741030161" From: Dave Katz In-Reply-To: Date: Thu, 28 Oct 2010 11:11:15 -0600 Message-ID: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> References: To: Palanivelan A X-Mailer: Apple Mail (2.1081) 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: Thu, 28 Oct 2010 17:10:39 -0000 --Apple-Mail-21-741030161 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Oct 28, 2010, at 7:01 AM, Palanivelan A (apvelan) wrote: > =20 > We see BFD to be serving what it is meant to and the wide = implementations of this technology points to its acceptance. > If we have to pick at the areas that are little grey, BFD for routing = protocols with GR comes as one of them. If there is a need to describe how to do GR more explicitly, a BCP would = be the ideal vehicle, as an implementation that follows it would = continue to be interoperable with other implementations that don't do = the function. If an implementor is looking for a solution, one that = does not require modification of the protocol is actually a feasible = option, whereas modifying the protocol is not (at least not if = interoperability is a requirement, at least for a significant time.) But it appears that the proposed change simply doesn't work for the = primary interesting case (unscheduled restart with short detection = times) because, as far as I can tell, *nothing* can solve that problem, = and it also doesn't fix the issue with poor scheduling, which in any = case is an implementation problem that cannot be fixed by the protocol. > =20 > Though the success of BFd with GR depend on the system design and that = there can be different ways of addressing the issue in line with the = design, > This draft intended to provide a common solution that can be adopted. = This was originally intended for =93standards track=94. But as far as I can tell, it doesn't actually do what it purports to do, = and thus modifies the protocol to no useful end. > =20 > But this working group, within its rights felt that BFD would not look = for such an extension and that this need not be considered for a = standards track and > I am certainly not debating on that. The independent reviewers however = proposed that this draft can be recorded for future and hence were = willing to > consider this draft for a =93Historic=94 status.The revisions to this = draft were all based on these review comments. I don't think that there is any mechanism for an ID to achieve Historic = status (which is a misnomer in this case), though I'm not an IETF = process expert; IDs are purged after six months. If I understand = correctly, Historic status is used to classify older RFCs whose = technology has been abandoned or otherwise overtaken by events. I don't = believe there is any mechanism by which this draft can be archived = within the IETF. As far as I can tell, the draft was last discussed in public in July of = 2009 (which I suppose is why I was confused about how it came to have = six more revisions since then) and the only comments boiled down to = "this isn't necessary". When it popped up again on the list yesterday, = I took a harder look and came to the conclusion that it is not only = unnecessary, but won't solve any problems that aren't already solvable = by the RFCs. I appreciate the fact that you're interested enough in the problem to = take the time to write and edit a draft, and I certainly don't want to = dissuade you. But I would urge you to put that energy into a draft that = clarifies the functional and implementation issues with GR in a way that = operates within the existing standards track documents; such a draft = could end up as an RFC and suitably recorded. --Dave --Apple-Mail-21-741030161 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
We = see BFD to be serving what it is meant to and the wide implementations = of this technology points to its acceptance.
If we have to pick at the areas = that are little grey, BFD for routing protocols with GR comes as one of = them.

If = there is a need to describe how to do GR more explicitly, a BCP would be = the ideal vehicle, as an implementation that follows it would continue = to be interoperable with other implementations that don't do the = function.  If an implementor is looking for a solution, one that = does not require modification of the protocol is actually a feasible = option, whereas modifying the protocol is not (at least not if = interoperability is a requirement, at least for a significant = time.)

But it appears that the proposed = change simply doesn't work for the primary interesting case (unscheduled = restart with short detection times) because, as far as I can tell, = *nothing* can solve that problem, and it also doesn't fix the issue with = poor scheduling, which in any case is an implementation problem that = cannot be fixed by the protocol.

This = draft intended to provide a common solution that can be adopted. This = was originally intended for =93standards = track=94.

But = as far as I can tell, it doesn't actually do what it purports to do, and = thus modifies the protocol to no useful end.

But = this working group, within its rights felt that BFD would not look for = such an extension and that this need not be considered for a standards = track and
I am = certainly not debating on that. The independent reviewers however = proposed that this draft can be recorded for future and hence were = willing to

I appreciate the fact = that you're interested enough in the problem to take the time to write = and edit a draft, and I certainly don't want to dissuade you.  But = I would urge you to put that energy into a draft that clarifies the = functional and implementation issues with GR in a way that operates = within the existing standards track documents;  such a draft could = end up as an RFC and suitably = recorded.

--Dave

= --Apple-Mail-21-741030161-- From d3e3e3@gmail.com Thu Oct 28 12:08: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 5CF7E3A6870 for ; Thu, 28 Oct 2010 12:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, 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 mqNT12O5FYJt for ; Thu, 28 Oct 2010 12:08:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BFEC33A6948 for ; Thu, 28 Oct 2010 12:08:13 -0700 (PDT) Received: by wyb28 with SMTP id 28so2205379wyb.31 for ; Thu, 28 Oct 2010 12:10:06 -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 :content-transfer-encoding; bh=jkRkhP2r/8KwSTpJFscVXsdnzJosBBcGu0WMCXIb9VM=; b=UAkTJerm/Fm8fAUk/XVzXv6kH4Q3zHIaywCVt4NpC3GQ+hJ81yemafXzuY/yDmc1cl nlrdjYe/Ko5jK0llx0Ix3aBiSjpD0b4Tumxa1oZYgr0/13bSQlmD0At0jbX2EbUFK76w mkpaEcf60YlYkR9s7x+0+L7osI5oIaourQuKQ= 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=C+rSGpM82OinnTR5zR98X2C5Ye4yAkJ+Y7gFCbFinNzlzHbgEaCR1f/ENOa2L67FCx URR9pqynQeSGKrsayVFC1oS0QM3Rra3+vui29RTxqhiDWang5fW0TUsJfv+yGItPbDMv 9O0DZukWmYApKL8WxJuam0m2+rjkK2DL5OomE= MIME-Version: 1.0 Received: by 10.227.137.17 with SMTP id u17mr11392579wbt.129.1288293005511; Thu, 28 Oct 2010 12:10:05 -0700 (PDT) Received: by 10.227.97.30 with HTTP; Thu, 28 Oct 2010 12:10:05 -0700 (PDT) In-Reply-To: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> References: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> Date: Thu, 28 Oct 2010 15:10:05 -0400 Message-ID: Subject: Re: draft-palanivelan-bfd-v2-gr-08 From: Donald Eastlake To: Dave Katz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd WG , Palanivelan A 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, 28 Oct 2010 19:08:15 -0000 On Thu, Oct 28, 2010 at 1:11 PM, Dave Katz wrote: >... > I don't think that there is any mechanism for an ID to achieve Historic > status (which is a misnomer in this case), though I'm not an IETF process > expert; =A0IDs are purged after six months. =A0If I understand correctly, > Historic status is used to classify older RFCs whose technology has been > abandoned or otherwise overtaken by events. =A0I don't believe there is a= ny > mechanism by which this draft can be archived within the IETF. A number of RFCs have been issued originally as Historic. The most recent three were RFC 6037, RFC 5806, and RFC 5773 for which the official announcements are here: https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D8514&t= id=3D1288292436 https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D7673&t= id=3D1288292698 https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D7505&t= id=3D1288292756 Donald From dkatz@juniper.net Thu Oct 28 12:47:07 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9413A6774 for ; Thu, 28 Oct 2010 12:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.378, 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 SNBEYHQU5+re for ; Thu, 28 Oct 2010 12:47:01 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 20EC03A6870 for ; Thu, 28 Oct 2010 12:47:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTMnTkTcwbG84rjZU2Pc7yc7X40+KCemf@postini.com; Thu, 28 Oct 2010 12:48:54 PDT 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; Thu, 28 Oct 2010 12:44:49 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o9SJinb80567; Thu, 28 Oct 2010 12:44:49 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: draft-palanivelan-bfd-v2-gr-08 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Thu, 28 Oct 2010 13:44:48 -0600 Content-Transfer-Encoding: quoted-printable Message-ID: References: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> To: Donald Eastlake X-Mailer: Apple Mail (2.1081) Cc: rtg-bfd WG , Palanivelan A 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, 28 Oct 2010 19:47:08 -0000 I stand corrected. I assume that there is at least some hurdle to cross to publish a = Historic RFC; otherwise I could publish my grocery lists or something. = ;-) --Dave On Oct 28, 2010, at 1:10 PM, Donald Eastlake wrote: > On Thu, Oct 28, 2010 at 1:11 PM, Dave Katz wrote: >> ... >> I don't think that there is any mechanism for an ID to achieve = Historic >> status (which is a misnomer in this case), though I'm not an IETF = process >> expert; IDs are purged after six months. If I understand correctly, >> Historic status is used to classify older RFCs whose technology has = been >> abandoned or otherwise overtaken by events. I don't believe there is = any >> mechanism by which this draft can be archived within the IETF. >=20 > A number of RFCs have been issued originally as Historic. The most > recent three were RFC 6037, RFC 5806, and RFC 5773 for which the > official announcements are here: >=20 > = https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D8514&= tid=3D1288292436 > = https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D7673&= tid=3D1288292698 > = https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D7505&= tid=3D1288292756 >=20 > Donald >=20 >=20 From d3e3e3@gmail.com Thu Oct 28 12:59:07 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6111C3A689B for ; Thu, 28 Oct 2010 12:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, 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 JSMn-3lSaDTK for ; Thu, 28 Oct 2010 12:59:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2D14B3A6774 for ; Thu, 28 Oct 2010 12:59:06 -0700 (PDT) Received: by wyb28 with SMTP id 28so2250231wyb.31 for ; Thu, 28 Oct 2010 13:00:58 -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 :content-transfer-encoding; bh=sUUXBRDBbXLF6ot17YXfbrQtcwZDdIlw2WszfJGGe8w=; b=TKfv2DPNgm0px7DOyoS3Ij0jggGtMxVLnreRvP0advF0QU/QHwQkLr6e8LST365lyS H8tYbTplUfWV8reuPK4SZ/0VYFoxsNVT1U4au6i+ZHUpkLK42WTbnff4BE6maXS856Nu wqa07caVX+Fsp9CLiSAFsP07tu6RPJTBbspfk= 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=pO6/fa+hzGcPPR3jT3uRk7PgIx8zWWccuN3bWUQNEbHdWkDl8Ypsp0A/jbXm9CbQiZ yBZSoXsZ0g8pnR1GhXz6TF5MqBXXv+DKUTwvFq/dnBXgOBRMBEpXHW5FTOzq8LEALbDB TR0hiQm/2H+GWggAQEVbCkQokMbtmerW53o+E= MIME-Version: 1.0 Received: by 10.227.132.70 with SMTP id a6mr9356323wbt.85.1288296058351; Thu, 28 Oct 2010 13:00:58 -0700 (PDT) Received: by 10.227.97.30 with HTTP; Thu, 28 Oct 2010 13:00:58 -0700 (PDT) In-Reply-To: References: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> Date: Thu, 28 Oct 2010 16:00:58 -0400 Message-ID: Subject: Re: draft-palanivelan-bfd-v2-gr-08 From: Donald Eastlake To: Dave Katz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd WG , Palanivelan A 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, 28 Oct 2010 19:59:07 -0000 Who knows, I've never done it. For all I know it may be more difficult than publishing a standards track document :-) Thanks, Donald On Thu, Oct 28, 2010 at 3:44 PM, Dave Katz wrote: > I stand corrected. > > I assume that there is at least some hurdle to cross to publish a Histori= c RFC; =A0otherwise I could publish my grocery lists or something. =A0;-) > > --Dave > > On Oct 28, 2010, at 1:10 PM, Donald Eastlake wrote: > >> On Thu, Oct 28, 2010 at 1:11 PM, Dave Katz wrote: >>> ... >>> I don't think that there is any mechanism for an ID to achieve Historic >>> status (which is a misnomer in this case), though I'm not an IETF proce= ss >>> expert; =A0IDs are purged after six months. =A0If I understand correctl= y, >>> Historic status is used to classify older RFCs whose technology has bee= n >>> abandoned or otherwise overtaken by events. =A0I don't believe there is= any >>> mechanism by which this draft can be archived within the IETF. >> >> A number of RFCs have been issued originally as Historic. The most >> recent three were RFC 6037, RFC 5806, and RFC 5773 for which the >> official announcements are here: >> >> https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D851= 4&tid=3D1288292436 >> https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D767= 3&tid=3D1288292698 >> https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D750= 5&tid=3D1288292756 >> >> Donald >> >> > > From apvelan@cisco.com Thu Oct 28 23:33:11 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 0BC3B3A6A08 for ; Thu, 28 Oct 2010 23:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.747 X-Spam-Level: X-Spam-Status: No, score=-9.747 tagged_above=-999 required=5 tests=[AWL=0.852, 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 BT+0gxC4gPVT for ; Thu, 28 Oct 2010 23:33:06 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C24703A6A09 for ; Thu, 28 Oct 2010 23:32:44 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHwHykxAaMHG/2dsb2JhbAChVHGgMJwshUgEhFWJDA X-IronPort-AV: E=Sophos;i="4.58,257,1286150400"; d="scan'208";a="287801613" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2010 06:34:02 +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 o9T6Xnrr012521; Fri, 29 Oct 2010 06:34:01 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); Fri, 29 Oct 2010 12:03:59 +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: Fri, 29 Oct 2010 12:03:57 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act22StwywvTSDfjQXeBlshzASajbwAVBLxw References: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> From: "Palanivelan A (apvelan)" To: "Dave Katz" , "Donald Eastlake" X-OriginalArrivalTime: 29 Oct 2010 06:33:59.0871 (UTC) FILETIME=[453ACCF0:01CB7733] 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: Fri, 29 Oct 2010 06:33:11 -0000 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. Regards, A.Palanivelan -----Original Message----- From: Dave Katz [mailto:dkatz@juniper.net]=20 Sent: Friday, October 29, 2010 1:15 AM To: Donald Eastlake Cc: rtg-bfd WG; Palanivelan A (apvelan) Subject: Re: draft-palanivelan-bfd-v2-gr-08 I stand corrected. I assume that there is at least some hurdle to cross to publish a Historic RFC; otherwise I could publish my grocery lists or something. ;-) --Dave On Oct 28, 2010, at 1:10 PM, Donald Eastlake wrote: > On Thu, Oct 28, 2010 at 1:11 PM, Dave Katz wrote: >> ... >> I don't think that there is any mechanism for an ID to achieve Historic >> status (which is a misnomer in this case), though I'm not an IETF process >> expert; IDs are purged after six months. If I understand correctly, >> Historic status is used to classify older RFCs whose technology has been >> abandoned or otherwise overtaken by events. I don't believe there is any >> mechanism by which this draft can be archived within the IETF. >=20 > A number of RFCs have been issued originally as Historic. The most > recent three were RFC 6037, RFC 5806, and RFC 5773 for which the > official announcements are here: >=20 > https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D8514= &tid=3D1288 292436 > https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D7673= &tid=3D1288 292698 > https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D7505= &tid=3D1288 292756 >=20 > Donald >=20 >=20 From dkatz@juniper.net Fri Oct 29 10:04:45 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 89FDC3A686C for ; Fri, 29 Oct 2010 10:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.241 X-Spam-Level: X-Spam-Status: No, score=-6.241 tagged_above=-999 required=5 tests=[AWL=0.358, 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 CTYOFkZAV7Hq for ; Fri, 29 Oct 2010 10:04:44 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 94B373A67DB for ; Fri, 29 Oct 2010 10:04:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTMr/H4OVNRe8N9mWZi38FVoomh6Iu3AU@postini.com; Fri, 29 Oct 2010 10:06:39 PDT 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, 29 Oct 2010 10:03:57 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o9TH3vb07629; Fri, 29 Oct 2010 10:03:57 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: draft-palanivelan-bfd-v2-gr-08 MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Fri, 29 Oct 2010 11:03:56 -0600 Content-Transfer-Encoding: quoted-printable Message-ID: References: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> To: Palanivelan A X-Mailer: Apple Mail (2.1081) 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: Fri, 29 Oct 2010 17:04:45 -0000 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 apvelan@cisco.com Sat Oct 30 00:00: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 275323A682C for ; Sat, 30 Oct 2010 00:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=-3.270, 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 gexZGgqgoPc0 for ; Fri, 29 Oct 2010 23:59:59 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E00883A67A8 for ; Fri, 29 Oct 2010 23:59:58 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcEAItfy0yQ/khNgWdsb2JhbAChRxUBARYiIqAZm2GFRASEVYkN X-IronPort-AV: E=Sophos;i="4.58,263,1286150400"; d="scan'208";a="12303654" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 30 Oct 2010 07:01:54 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9U71qKj021609; Sat, 30 Oct 2010 07:01:54 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); Sat, 30 Oct 2010 12:31:53 +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: Sat, 30 Oct 2010 12:31:43 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-palanivelan-bfd-v2-gr-08 Thread-Index: Act3i65W1yk6Mk4jT46fkkpkBhpHuAAdEsRQ References: <624AA73F-B922-45D4-B934-1BFD9F9E629D@juniper.net> From: "Palanivelan A (apvelan)" To: "Dave Katz" X-OriginalArrivalTime: 30 Oct 2010 07:01:53.0954 (UTC) FILETIME=[55795820:01CB7800] 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: Sat, 30 Oct 2010 07:00:00 -0000 Hi Dave, Thanks for that encouraging mail. Let me do it as per your suggestion and analyzing and discussing the gaps in depth definitely helps. 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