From jhaas@slice.pfrc.org Fri Jun 1 07:12:44 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78BF11E8089 for ; Fri, 1 Jun 2012 07:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.058 X-Spam-Level: X-Spam-Status: No, score=-101.058 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kkpt3p9RySV5 for ; Fri, 1 Jun 2012 07:12:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB0411E8085 for ; Fri, 1 Jun 2012 07:12:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 0ED9AD26C; Fri, 1 Jun 2012 10:12:43 -0400 (EDT) Date: Fri, 1 Jun 2012 10:12:43 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 84 Message-ID: <20120601141243.GP4067@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2012 14:12:44 -0000 We will be meeting during IETF 84. Please start thinking about requests for agenda slots. -- Jeff From jhaas@slice.pfrc.org Fri Jun 1 07:40:12 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53521F88B2 for ; Fri, 1 Jun 2012 07:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.662 X-Spam-Level: X-Spam-Status: No, score=-101.662 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REAzT4-Rzw6f for ; Fri, 1 Jun 2012 07:40:12 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09721F8881 for ; Fri, 1 Jun 2012 07:40:12 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E4611D238; Fri, 1 Jun 2012 10:40:11 -0400 (EDT) Date: Fri, 1 Jun 2012 10:40:11 -0400 From: Jeffrey Haas To: Donald Eastlake Subject: Re: Fwd: Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) to Proposed Standard Message-ID: <20120601144011.GQ4067@pfrc> References: <20120523211548.28200.46941.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtg-bfd WG , trill-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2012 14:40:12 -0000 Donald (and authors), One minor editorial comment: RFC 5881 should probably be an informative reference. On Wed, May 23, 2012 at 05:23:01PM -0400, Donald Eastlake wrote: > Hi, > > This draft passed TRILL WG Last Call (notice of which was previous > posted to the BFD WG) and is now in IETF Last Call. > > Thanks, > Donald > ============================= > ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell) > ?155 Beaver Street,?Milford, MA 01757 USA > ?d3e3e3@gmail.com -- Jeff From jhaas@slice.pfrc.org Fri Jun 1 08:12:41 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BAA11E819E for ; Fri, 1 Jun 2012 08:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.795 X-Spam-Level: X-Spam-Status: No, score=-101.795 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmAmngYhd1db for ; Fri, 1 Jun 2012 08:12:41 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E011E80F3 for ; Fri, 1 Jun 2012 08:12:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6B269D271; Fri, 1 Jun 2012 11:12:38 -0400 (EDT) Date: Fri, 1 Jun 2012 11:12:38 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Adoption of draft-vkst-bfd-mpls-mib Message-ID: <20120601151238.GV4067@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2012 15:12:41 -0000 Working Group, This begins a one week poll for the adoption of http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib as a working group document. Note that this appears to be currently within the scope of our charter: : 1. Develop the MIB module for BFD and submit it to the IESG for publication : as a Proposed Standard. : : 5. Assist in the standardization of the BFD protocol for MPLS-TP. The : preferred solution will be interoperable with the current BFD specification. If our ADs disagree, we'll ask for a formal charter change to pick up this item. The room discussion regarding this draft during IETF 83 was positive. -- Jeff From d3e3e3@gmail.com Fri Jun 1 09:05:30 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBA111E80D2 for ; Fri, 1 Jun 2012 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMHq1t9mWAih for ; Fri, 1 Jun 2012 09:05:30 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24F5911E80BC for ; Fri, 1 Jun 2012 09:05:30 -0700 (PDT) Received: by yenq13 with SMTP id q13so2116028yen.31 for ; Fri, 01 Jun 2012 09:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=/lNv8VA+AiIik9w8V8ocu1R0bArKkkZ2gF7FuD14iD0=; b=YZeUX4Y8F+AxpDB0w1oZ6mSV7niwsuloZ6BhFuvFAwVIswSCH7iMuSDSt9wGUha9z/ zshNMV+5LlBDQV7GXPRrLYO8gl4FJYkIQ6toQjwUfbHlO/qexgxHUrczGdboVK3WOlc2 KR+iub1FtI+zc+rH74E7K5ISY4Vf7pnoTMYYbVYbyqK4fv7oOUDPzUab3Rp2tEnFjOcM a1wnW40DZk8A5kwfIijvzHALge1RObhyCYdnGiFoeyOUHN+rpMJGmUI0W2WxHUcQpmDS XX4XdRfzHwIZJbFuWZWgEP5yrXuP/uyVuTYOlp9UlCLn0/jVH3Q3Qi98PBlfP29VncT3 3upg== Received: by 10.42.153.10 with SMTP id k10mr2288709icw.24.1338566729103; Fri, 01 Jun 2012 09:05:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.99.228 with HTTP; Fri, 1 Jun 2012 09:05:08 -0700 (PDT) In-Reply-To: <20120601144011.GQ4067@pfrc> References: <20120523211548.28200.46941.idtracker@ietfa.amsl.com> <20120601144011.GQ4067@pfrc> From: Donald Eastlake Date: Fri, 1 Jun 2012 12:05:08 -0400 Message-ID: Subject: Re: Fwd: Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) to Proposed Standard To: Jeffrey Haas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd WG , draft-ietf-trill-rbridge-bfd@tools.ietf.org, trill-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2012 16:05:30 -0000 Hi Jeff, On Fri, Jun 1, 2012 at 10:40 AM, Jeffrey Haas wrote: > Donald (and authors), > > One minor editorial comment: RFC 5881 should probably be an informative > reference. Thanks for the comment. The two places where RFC 5881 is referenced are in Sections 2 and 5 where this draft says: "BFD over TRILL support is similar to BFD over IP support [RFC5881] except where differences are explicitly mentioned." and "... TRILL BFD parameters ... The default values are the same as in the IP BFD case [RFC5881], except where specified in this document such as for Hop Count." Perhaps, in the first quote above, "similar to" should be changed to "the same as". In any case, at least the second quote looks kind of normative to me.... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > On Wed, May 23, 2012 at 05:23:01PM -0400, Donald Eastlake wrote: >> Hi, >> >> This draft passed TRILL WG Last Call (notice of which was previous >> posted to the BFD WG) and is now in IETF Last Call. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell) >> ?155 Beaver Street,?Milford, MA 01757 USA >> ?d3e3e3@gmail.com > > -- Jeff From jhaas@slice.pfrc.org Fri Jun 1 09:14:47 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF5A11E8104 for ; Fri, 1 Jun 2012 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.946 X-Spam-Level: X-Spam-Status: No, score=-101.946 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GkVshAAGWIi for ; Fri, 1 Jun 2012 09:14:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5B98511E80EA for ; Fri, 1 Jun 2012 09:14:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2780CD2A1; Fri, 1 Jun 2012 12:14:47 -0400 (EDT) Date: Fri, 1 Jun 2012 12:14:47 -0400 From: Jeffrey Haas To: Donald Eastlake Subject: Re: Fwd: Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) to Proposed Standard Message-ID: <20120601161447.GW4067@pfrc> References: <20120523211548.28200.46941.idtracker@ietfa.amsl.com> <20120601144011.GQ4067@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtg-bfd WG , draft-ietf-trill-rbridge-bfd@tools.ietf.org, trill-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2012 16:14:48 -0000 Donald, On Fri, Jun 01, 2012 at 12:05:08PM -0400, Donald Eastlake wrote: > On Fri, Jun 1, 2012 at 10:40 AM, Jeffrey Haas wrote: > > One minor editorial comment: RFC 5881 should probably be an informative > > reference. > [...] > and > "... TRILL BFD parameters ... The default > values are the same as in the IP BFD case [RFC5881], except where > specified in this document such as for Hop Count." > > Perhaps, in the first quote above, "similar to" should be changed to > "the same as". In any case, at least the second quote looks kind of > normative to me.... I had missed the second item and I agree with you. I withdraw my comment. :-) -- Jeff From adrian@olddog.co.uk Sat Jun 2 09:31:19 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597CF21F85D2 for ; Sat, 2 Jun 2012 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHDYyTvBBNBD for ; Sat, 2 Jun 2012 09:31:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7315621F85C9 for ; Sat, 2 Jun 2012 09:31:18 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q52GVGdZ017976; Sat, 2 Jun 2012 17:31:16 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q52GVF9j017970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 2 Jun 2012 17:31:16 +0100 From: "Adrian Farrel" To: "'Jeffrey Haas'" , References: <20120601151238.GV4067@pfrc> In-Reply-To: <20120601151238.GV4067@pfrc> Subject: RE: Adoption of draft-vkst-bfd-mpls-mib Date: Sat, 2 Jun 2012 17:31:11 +0100 Message-ID: <047201cd40dd$1fa74b60$5ef5e220$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEfVf3lCO5qOclBQXxpO/vHAo/vDJhDCwKg Content-Language: en-gb X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 16:31:19 -0000 Hi Jeff, I don't disagree: this is clearly part of your charter. The document claims to extend BFD-STD-MIB but there is no citation for that module and I can find no active document on the charter page that includes that module. Has something timed out? Is the cart in front of the horse? And a meta-question (arising from recent pushback I have been getting for MIB modules within the IESG)... Notwithstanding MIB modules being a deliverable of the WG, you should only work on them if there is a clear desire to build them into product and use them in deployments. You should not spend cycles making MIBs just because they are in the charter, and certainly not just because "here is a chance to publish an RFC" :-) Lastly, a number of objects in the module are read-create. This implies that the plan is for the module to be used for (or at least capable of being used for) configuring BFD behavior, not just monitoring it. I would like the WG to be certain that this is function it wants. But that question does not need to gate adoption if the WG chooses to work on the I-D. Cheers, Adrian > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Jeffrey Haas > Sent: 01 June 2012 16:13 > To: rtg-bfd@ietf.org > Subject: Adoption of draft-vkst-bfd-mpls-mib > > Working Group, > > This begins a one week poll for the adoption of > http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib > as a working group document. > > Note that this appears to be currently within the scope of our charter: > > : 1. Develop the MIB module for BFD and submit it to the IESG for publication > : as a Proposed Standard. > : > : 5. Assist in the standardization of the BFD protocol for MPLS-TP. The > : preferred solution will be interoperable with the current BFD specification. > > If our ADs disagree, we'll ask for a formal charter change to pick up this > item. > > The room discussion regarding this draft during IETF 83 was positive. > > -- Jeff From jhaas@slice.pfrc.org Sat Jun 2 16:00:59 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FE421F84DD for ; Sat, 2 Jun 2012 16:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.943 X-Spam-Level: X-Spam-Status: No, score=-101.943 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJHDrFUHjgS7 for ; Sat, 2 Jun 2012 16:00:59 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1C53921F84CD for ; Sat, 2 Jun 2012 16:00:58 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9C3C1D313; Sat, 2 Jun 2012 19:00:58 -0400 (EDT) Date: Sat, 2 Jun 2012 19:00:58 -0400 From: Jeffrey Haas To: Adrian Farrel Subject: Re: Adoption of draft-vkst-bfd-mpls-mib Message-ID: <20120602230058.GY4067@pfrc> References: <20120601151238.GV4067@pfrc> <047201cd40dd$1fa74b60$5ef5e220$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <047201cd40dd$1fa74b60$5ef5e220$@olddog.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtg-bfd@ietf.org, mpls-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 02 Jun 2012 23:00:59 -0000 Adrian, On Sat, Jun 02, 2012 at 05:31:11PM +0100, Adrian Farrel wrote: > The document claims to extend BFD-STD-MIB but there is no citation for that > module and I can find no active document on the charter page that includes that > module. Has something timed out? Is the cart in front of the horse? Yes, it's timed out. It's in the enviable position of being also ready for last call, but only once the authors republish it. (Which they've been prodded to do a few times in the last couple of months.) > And a meta-question (arising from recent pushback I have been getting for MIB > modules within the IESG)... > Notwithstanding MIB modules being a deliverable of the WG, you should only work > on them if there is a clear desire to build them into product and use them in > deployments. You should not spend cycles making MIBs just because they are in > the charter, and certainly not just because "here is a chance to publish an RFC" As anyone who follows MIBs is aware, I'm hardly the last person to say "let's do a MIB, just because". :-) > Lastly, a number of objects in the module are read-create. This implies that the > plan is for the module to be used for (or at least capable of being used for) > configuring BFD behavior, not just monitoring it. I would like the WG to be > certain that this is function it wants. But that question does not need to gate > adoption if the WG chooses to work on the I-D. As part of the IETF MPLS-TP work, I believe we (the IETF) are expected to provide interfaces to configure that feature. While I'll admit to not playing enough in that field to know what the latest conversations have been on this topic, the current choices are either SNMP or netconf. I believe there is more support for SNMP at this point. It's probably worth prodding the MPLS chairs to offer a public opinion on the matter. I've cc'd them on this and will also forward the original email to them. -- Jeff From saravanannarasimhan@gmail.com Sun Jun 3 00:08:08 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFF021F85A8 for ; Sun, 3 Jun 2012 00:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qpRM7eT+lHu for ; Sun, 3 Jun 2012 00:08:08 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF321F85A2 for ; Sun, 3 Jun 2012 00:08:08 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2788596ggn.31 for ; Sun, 03 Jun 2012 00:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fB1oFQ7q7ex1jvetreWsZkrsTB1MCrnEIjrqs9scWH8=; b=OQDSR6HCe57CNXNQpNcCs6eQfGqgSFz6P/Ft4frbOnRpW1iNRv0oTsIugs2QUGkufS lITwdfuNhsjikBAUTOs/hQOuOl4WeQLn5fEGkF2fYhbcoRvpsQx/qXLPXeDEzr9tLIFQ 8sjIEk5QA/TpFgFRZsqyMdT84L3eFctntqiGkwoq5NhcjXOWiMEOLfBnk+BGAnuPMV7+ zRiLIs4YYWBbUTd0zw7xUu36P/yyDsV0RKzOcPAv6ie2mQUeW67/OvCgoHpweIcby9a7 5ep3LLaSlzCck/Ft5baE1iRN+cwvIq1JS+1eJstJLCTLicHxJcxmbQHWHyijnPrZEq82 fPWQ== MIME-Version: 1.0 Received: by 10.236.190.199 with SMTP id e47mr3307211yhn.107.1338707287316; Sun, 03 Jun 2012 00:08:07 -0700 (PDT) Received: by 10.147.4.30 with HTTP; Sun, 3 Jun 2012 00:08:07 -0700 (PDT) Date: Sun, 3 Jun 2012 12:38:07 +0530 Message-ID: Subject: Questions on BFD MPLS MIB From: Saravanan Narasimhan To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=20cf305e21435199ee04c18c1409 X-Mailman-Approved-At: Sun, 03 Jun 2012 06:39:21 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 03 Jun 2012 07:08:09 -0000 --20cf305e21435199ee04c18c1409 Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, I have a question regarding the Section 5.2.1 of the draft draft-vkst-bfd-mpls-mib-02. It states that " bfdMplsSessMapType = teIpv4(3), -- OID of the first accessible object (mplsTunnelName) of -- the mplsTunnelEntry identifying the MPLS TE tunnel (being -- monitored using BFD) in the MPLS tunnel table. -- A value of zeroDotzero indicates that no association -- has been made as yet between the BFD session and the path -- being monitored. -- In the above OID example: -- 100 -> Tunnel Index -- 1 -> Tunnel instance -- 3221225985 -> Ingress LSR Id 192.0.2.1 -- 3221225987 -> Egress LSR Id 192.0.2.3 bfdMplsSessMapPointer = mplsTunnelName.100.1.3221225985.3221225987, bfdSessRowStatus = createAndGo } Similarly BFD session would be configured on the tail-end of the tunnel. " Here, at the tail-end of the tunnel, "Instance" is never really known. Tunnel can be setup with any tunnel instance (LSP ID) when it is signaled through RSVP-TE / CR-LDP. It need not be "1" as mentioned in the above example. So, We should be setting the map pointer as "bfdMplsSessMapPointer = mplsTunnelName.100.0.3221225985.3221225987". Am I right? Or should we take the approach as defined in PW-MPLS-STD-MIB (RFC 5602) where OutboundTunnel is mapped to the PW through individual objects (pwMplsOutboundTunnelIndex, pwMplsOutboundTunnelInstance, pwMplsOutboundTunnelLclLSR and pwMplsOutboundTunnelPeerLSR with pwMplsOutboundTunnelInstance as a READ-ONLY parameter) instead of a RowPointer approach done here. Please clarify. Also, Can you please clarify how this MIB can be used to monitor a tunnel setup through 1:1 protection support (RSVP-TE signaling as in RFC 4872) (2 LSP's -> Working and Protection)? Should we create 2 independent BFD sessions to monitor working and protection LSP or a single BFD session to monitor both? If we need to create 2 BFD sessions, how to map tunnel pointer to BFD session? Please clarify. Thank You, N.Saravanan --20cf305e21435199ee04c18c1409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Authors,

I have a question regarding the Section 5.2.1 of the dra= ft draft-vkst-bfd-mpls-mib-02.

It states that

" bfdMpl= sSessMapType =3D teIpv4(3),

=A0-- OID of the first accessibl= e object (mplsTunnelName) of
=A0-- the mplsTunnelEntry identifying the MPLS TE tunnel (being= =20 -- monitored using BFD) in the MPLS tunnel table.=20
=A0-- A value of zeroDotzero indicates that no association -- has been made as yet between the BFD session and the path
=A0-- being monitored.=20
=A0-- In the above OID example:=20
=A0-- 100 -> Tunnel Index
=A0-- 1 -> Tunnel instance=20
=A0-- 3221225985 -> Ingress LSR Id 192.0.2.1
=A0-- 3221225987 -> Egress LSR Id 192.0.2.3

=A0=A0=A0 bfdMplsSessMapPointer=20 =3D mplsTunnelName.100.1.3221225985.3221225987, =20
=A0=A0=A0 bfdSessRowStatus =3D createAndGo
}

Similarly BFD session would be configured on the tail-end o= f=20 the tunnel.

"

Here, at the tail-end of the tunne= l, "Instance" is never really known. Tunnel can be setup with any= tunnel instance (LSP ID) when it is signaled through RSVP-TE / CR-LDP. It = need not be "1" as mentioned in the above example.

So, We should be setting the map pointer as

"bfdMplsSessMa= pPointer =3D mplsTunnelName.100.0.3221225985.3221225987". Am I right?<= br>
Or should we take the approach as defined in PW-MPLS-STD-MIB (RFC 56= 02) where OutboundTunnel is mapped to the PW through individual objects (pw= MplsOutboundTunnelIndex, pwMplsOutboundTunnelInstance, pwMplsOutboundTunnel= LclLSR and pwMplsOutboundTunnelPeerLSR with pwMplsOutboundTunnelInstance as= a READ-ONLY parameter) instead of a RowPointer approach done here. Please = clarify.

Also, Can you please clarify how this MIB can be used to monitor a tunn= el setup through 1:1 protection support (RSVP-TE signaling as in RFC 4872) = (2 LSP's -> Working and Protection)?

Should we create 2 inde= pendent BFD sessions to monitor working and protection LSP or a single BFD = session to monitor both?

If we need to create 2 BFD sessions, how to map tunnel pointer to BFD s= ession?

Please clarify.

Thank You,
N.Saravanan
--20cf305e21435199ee04c18c1409-- From venkatflex@gmail.com Mon Jun 4 20:28:28 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F6C11E80B4; Mon, 4 Jun 2012 20:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGLtuImQ4bNL; Mon, 4 Jun 2012 20:28:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E82ED21F86A0; Mon, 4 Jun 2012 20:28:27 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3268977vbb.31 for ; Mon, 04 Jun 2012 20:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JnjCCBWbkJa6wZVQcqw7oErAeDGaclj8/MM7MqeK4s4=; b=Z4gje8XpJSm3AW8FNkRSwBHGnPx5+Mx8zNIcucG3MKpX5mzajKa6w2gq2e5+XSCt4d mKS58I1yAiwmBouazLPknyrpq7qJm8GbixQsDNdBE0hvjserLsu9Jb3qk7uUU0PccIOn PLL/sFc83fLWRIryqJGGrFAOFGZr3mNhJ/HlHhUJXuK8LVDEsuyMo3MtDkkquzbJGgIY TJDWBznxPl7csx0mf6GJR90agxn9V54wyO5XRwVTOrpIyVG3XlyauhSAwKzv67K0qd87 vr7xxNbDBOFeKb/gFBzvRAV+3gv3e85n/Qa2IUHYYjEgM3Q76BukQ94q+iSdSaLDmqpG rC8g== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr13005260vdb.10.1338866907306; Mon, 04 Jun 2012 20:28:27 -0700 (PDT) Received: by 10.220.34.205 with HTTP; Mon, 4 Jun 2012 20:28:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Jun 2012 20:28:27 -0700 Message-ID: Subject: Re: [mpls] Questions on BFD MPLS MIB From: venkatesan mahalingam To: Saravanan Narasimhan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mpls@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 03:28:29 -0000 Hi, Please find below the comments inline with the tag [VM]. Thanks, Venkat. On Sun, Jun 3, 2012 at 12:12 AM, Saravanan Narasimhan wrote: > Hi Authors, > > I have a question regarding the Section 5.2.1 of the draft > draft-vkst-bfd-mpls-mib-02. > > It states that > > " bfdMplsSessMapType =3D teIpv4(3), > > =A0-- OID of the first accessible object (mplsTunnelName) of > =A0-- the mplsTunnelEntry identifying the MPLS TE tunnel (being -- monito= red > using BFD) in the MPLS tunnel table. > =A0-- A value of zeroDotzero indicates that no association -- has been ma= de as > yet between the BFD session and the path > =A0-- being monitored. > =A0-- In the above OID example: > =A0-- 100 -> Tunnel Index > =A0-- 1 -> Tunnel instance > =A0-- 3221225985 -> Ingress LSR Id 192.0.2.1 > =A0-- 3221225987 -> Egress LSR Id 192.0.2.3 > > =A0=A0=A0 bfdMplsSessMapPointer =3D mplsTunnelName.100.1.3221225985.32212= 25987, > =A0=A0=A0 bfdSessRowStatus =3D createAndGo > } > > Similarly BFD session would be configured on the tail-end of the tunnel. > > " > > Here, at the tail-end of the tunnel, "Instance" is never really known. > Tunnel can be setup with any tunnel instance (LSP ID) when it is signaled > through RSVP-TE / CR-LDP. It need not be "1" as mentioned in the above > example. > > So, We should be setting the map pointer as > > "bfdMplsSessMapPointer =3D mplsTunnelName.100.0.3221225985.3221225987". A= m I > right? [VM] If I'm not wrong, tunnel instance 0 is reserved for configured tunnel, we should be able to get the LSP-id through RSVP-TE or out-of-band signalling (LSP Ping). > Or should we take the approach as defined in PW-MPLS-STD-MIB (RFC 5602) > where OutboundTunnel is mapped to the PW through individual objects > (pwMplsOutboundTunnelIndex, pwMplsOutboundTunnelInstance, > pwMplsOutboundTunnelLclLSR and pwMplsOutboundTunnelPeerLSR with > pwMplsOutboundTunnelInstance as a READ-ONLY parameter) instead of a > RowPointer approach done here. Please clarify. [VM] RowPointer approach should be fine. > Also, Can you please clarify how this MIB can be used to monitor a tunnel > setup through 1:1 protection support (RSVP-TE signaling as in RFC 4872) (= 2 > LSP's -> Working and Protection)? > > Should we create 2 independent BFD sessions to monitor working and > protection LSP or a single BFD session to monitor both? [VM] Yes, two independent BFD sessions are required to monitor both working and protection paths. > If we need to create 2 BFD sessions, how to map tunnel pointer to BFD > session? [VM] Either you can configure tunnel pointers at the head and tail nodes manually or use out-of-band signalling using on-demand CV. > > Please clarify. > > Thank You, > N.Saravanan > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From gregory.mirsky@ericsson.com Tue Jun 5 14:35:47 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8521F87BF for ; Tue, 5 Jun 2012 14:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rroMJ4-eLrs for ; Tue, 5 Jun 2012 14:35:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 51CA221F8792 for ; Tue, 5 Jun 2012 14:35:47 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q55LZjLT008895; Tue, 5 Jun 2012 16:35:46 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 5 Jun 2012 17:35:40 -0400 From: Gregory Mirsky To: Jeffrey Haas , "rtg-bfd@ietf.org" Date: Tue, 5 Jun 2012 17:35:39 -0400 Subject: RE: Adoption of draft-vkst-bfd-mpls-mib Thread-Topic: Adoption of draft-vkst-bfd-mpls-mib Thread-Index: Ac1ACQCaTVN67OsAROap5CM90BroeQDUXRZw Message-ID: References: <20120601151238.GV4067@pfrc> In-Reply-To: <20120601151238.GV4067@pfrc> 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 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 21:35:48 -0000 Dear Chairs, Authors, et al., I think that this is needed work but the document needs some modifications: - read-create objects can be modified into read-only as no firm requirement= to support SNMP based configuration can be found; - bfdMplsSessTable lacks object to reflect whether Coordinated or Independe= nt monitoring mode being used per RFC 6428; - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS specific b= ut is expression of local policy set by an operator. The bfdMplsSessTmrNego= tiate should be removed from the bfdMplsSessTable table; - list of modes for the bfdMplsSessMode object should include a mode, perha= ps referred as bfd, which performs continuity check but does not support RD= I functionality (RFC 5884 and RFC 5885); - bfdMplsSessTable needs to reflect addressing used if bfdMplsSessMapType = =3D mep(6) - IP or ICC; - bfdMplsSessTable needs to reflect encapsulation type, IP or ACH/G-ACh, be= ing used. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Friday, June 01, 2012 8:13 AM To: rtg-bfd@ietf.org Subject: Adoption of draft-vkst-bfd-mpls-mib Working Group, This begins a one week poll for the adoption of http://tools.ietf.org/html/= draft-vkst-bfd-mpls-mib as a working group document. Note that this appears to be currently within the scope of our charter: : 1. Develop the MIB module for BFD and submit it to the IESG for publicati= on : as a Proposed Standard.=20 :=20 : 5. Assist in the standardization of the BFD protocol for MPLS-TP. The : preferred solution will be interoperable with the current BFD specificati= on.=20 If our ADs disagree, we'll ask for a formal charter change to pick up this = item. The room discussion regarding this draft during IETF 83 was positive. -- Jeff From tnadeau@lucidvision.com Tue Jun 5 16:55:19 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCC911E808C for ; Tue, 5 Jun 2012 16:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+GRht2M2KIX for ; Tue, 5 Jun 2012 16:55:19 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 00A4711E8094 for ; Tue, 5 Jun 2012 16:55:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 5B7F521529F9; Tue, 5 Jun 2012 19:55:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzIpKn3KHkQY; Tue, 5 Jun 2012 19:55:17 -0400 (EDT) Received: from rajh-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) by lucidvision.com (Postfix) with ESMTP id A52B621529F6; Tue, 5 Jun 2012 19:55:16 -0400 (EDT) Subject: Re: Adoption of draft-vkst-bfd-mpls-mib Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: Date: Tue, 5 Jun 2012 16:55:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120601151238.GV4067@pfrc> To: Gregory Mirsky X-Mailer: Apple Mail (2.1278) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 23:55:19 -0000 On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote: > Dear Chairs, Authors, et al., > I think that this is needed work but the document needs some = modifications: > - read-create objects can be modified into read-only as no firm = requirement to support SNMP based configuration can be found; Are you asking us to specifically make the MIB read-only? If = so, this would be at least the second request recently (third if you = include mine). However, it might be good to get some guidance from the = WG chairs on this direction as making these changes can be potentially = significant. --Tom > - bfdMplsSessTable lacks object to reflect whether Coordinated or = Independent monitoring mode being used per RFC 6428; > - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS = specific but is expression of local policy set by an operator. The = bfdMplsSessTmrNegotiate should be removed from the bfdMplsSessTable = table; > - list of modes for the bfdMplsSessMode object should include a mode, = perhaps referred as bfd, which performs continuity check but does not = support RDI functionality (RFC 5884 and RFC 5885); > - bfdMplsSessTable needs to reflect addressing used if = bfdMplsSessMapType =3D mep(6) - IP or ICC; > - bfdMplsSessTable needs to reflect encapsulation type, IP or = ACH/G-ACh, being used. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Jeffrey Haas > Sent: Friday, June 01, 2012 8:13 AM > To: rtg-bfd@ietf.org > Subject: Adoption of draft-vkst-bfd-mpls-mib >=20 > Working Group, >=20 > This begins a one week poll for the adoption of = http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib > as a working group document. >=20 > Note that this appears to be currently within the scope of our = charter: >=20 > : 1. Develop the MIB module for BFD and submit it to the IESG for = publication > : as a Proposed Standard.=20 > :=20 > : 5. Assist in the standardization of the BFD protocol for MPLS-TP. = The > : preferred solution will be interoperable with the current BFD = specification.=20 >=20 > If our ADs disagree, we'll ask for a formal charter change to pick up = this item. >=20 > The room discussion regarding this draft during IETF 83 was positive. >=20 > -- Jeff >=20 From aldrin.ietf@gmail.com Tue Jun 5 17:35:41 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B11711E808D for ; Tue, 5 Jun 2012 17:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gKAOYsg0Fvu for ; Tue, 5 Jun 2012 17:35:40 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C48D11E808C for ; Tue, 5 Jun 2012 17:35:40 -0700 (PDT) Received: by dacx6 with SMTP id x6so7857007dac.31 for ; Tue, 05 Jun 2012 17:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=zwc+wdcOkWhJN88ofMwFbe4Oya/trFtQ1/eg6irOuvQ=; b=Fvv6RJgCOHpdRq9vJcXeRu+NWsUGhbnOZYtmdueR+UD/fk0eSAve4P9t0b6Vef+TFF scxSC7+BL4rNLJG4vJtazcvTuFu4NcTuX2HUMtwc2jVljylb+mmUjNHfeMpDm1OgOf6e UMW4Lb6mJ8XWqvKuGGcoGLTowAvvy+flJjF/4Qm/fF6ufUOIsbpuE2ny/TW+LC0BuGiT HS8M/VJiFdePScfx/IrxmFgh7BG2eEYE74j1WiIEgeFYNSTCikPhVDY81tnVBn0AmurV opu4uQrNug6GGVLMQHM2UQ7Oo5XsV56tYgsMac6WhylC1po5dZVWfwiljDh8Wk4JSeOy YArw== Received: by 10.68.237.202 with SMTP id ve10mr43455859pbc.54.1338942939944; Tue, 05 Jun 2012 17:35:39 -0700 (PDT) Received: from [199.187.220.60] (dhcp-220-60.meetings.nanog.org. [199.187.220.60]) by mx.google.com with ESMTPS id pb10sm471437pbc.68.2012.06.05.17.35.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jun 2012 17:35:38 -0700 (PDT) References: <20120601151238.GV4067@pfrc> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Sam Aldrin Subject: Re: Adoption of draft-vkst-bfd-mpls-mib Date: Tue, 5 Jun 2012 17:35:37 -0700 To: Thomas Nadeau Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2012 00:35:41 -0000 Sent from my iPad On Jun 5, 2012, at 4:55 PM, Thomas Nadeau wrote: >=20 > On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote: >=20 >> Dear Chairs, Authors, et al., >> I think that this is needed work but the document needs some modification= s: >> - read-create objects can be modified into read-only as no firm requireme= nt to support SNMP based configuration can be found; >=20 > Are you asking us to specifically make the MIB read-only? If so, this w= ould be at least the second request recently (third if you include mine). H= owever, it might be good to get some guidance from the WG chairs on this dir= ection as making these changes can be potentially significant. We were asked specifically by the WG chairs, in the Paris WG session, to add= read write option to the MIB. AD and MPLS WG chair also provided their comm= ents and felt BFD MIB extension to support TP should have write support. There are at least three vendors who are requesting write support as well. To the original comment that there is no requirement for write support for M= IB, my answer is, there is no requirement to have just read only either. If t= here is consensus that, write option shouldnt exist in MIBs, it should be st= ated so. Otherwise, the confusion will persist every time. Cheers Sam >=20 > --Tom >=20 >=20 >> - bfdMplsSessTable lacks object to reflect whether Coordinated or Indepen= dent monitoring mode being used per RFC 6428; >> - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS specific= but is expression of local policy set by an operator. The bfdMplsSessTmrNeg= otiate should be removed from the bfdMplsSessTable table; >> - list of modes for the bfdMplsSessMode object should include a mode, per= haps referred as bfd, which performs continuity check but does not support R= DI functionality (RFC 5884 and RFC 5885); >> - bfdMplsSessTable needs to reflect addressing used if bfdMplsSessMapType= =3D mep(6) - IP or ICC; >> - bfdMplsSessTable needs to reflect encapsulation type, IP or ACH/G-ACh, b= eing used. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Jeffrey Haas >> Sent: Friday, June 01, 2012 8:13 AM >> To: rtg-bfd@ietf.org >> Subject: Adoption of draft-vkst-bfd-mpls-mib >>=20 >> Working Group, >>=20 >> This begins a one week poll for the adoption of http://tools.ietf.org/htm= l/draft-vkst-bfd-mpls-mib >> as a working group document. >>=20 >> Note that this appears to be currently within the scope of our charter: >>=20 >> : 1. Develop the MIB module for BFD and submit it to the IESG for publica= tion >> : as a Proposed Standard.=20 >> :=20 >> : 5. Assist in the standardization of the BFD protocol for MPLS-TP. The >> : preferred solution will be interoperable with the current BFD specifica= tion.=20 >>=20 >> If our ADs disagree, we'll ask for a formal charter change to pick up thi= s item. >>=20 >> The room discussion regarding this draft during IETF 83 was positive. >>=20 >> -- Jeff >>=20 >=20 From gregory.mirsky@ericsson.com Tue Jun 5 17:42:22 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57521F85D9 for ; Tue, 5 Jun 2012 17:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvFzyq1GQKEC for ; Tue, 5 Jun 2012 17:42:22 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E51C021F85D7 for ; Tue, 5 Jun 2012 17:42:21 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q560gCff012674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jun 2012 19:42:21 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.66]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 5 Jun 2012 20:42:11 -0400 From: Gregory Mirsky To: Thomas Nadeau Date: Tue, 5 Jun 2012 20:42:09 -0400 Subject: RE: Adoption of draft-vkst-bfd-mpls-mib Thread-Topic: Adoption of draft-vkst-bfd-mpls-mib Thread-Index: Ac1DdqpKbntZ+tROTVmwM11sSwCRDwABcHwg Message-ID: References: <20120601151238.GV4067@pfrc> 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" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2012 00:42:22 -0000 Hi Tom, yes, you can count me in. As for "guidance from the WG chairs", Which worki= ng group should provide such guidance - RTG-BFD or MPLS? Regards, Greg -----Original Message----- From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Tuesday, June 05, 2012 4:55 PM To: Gregory Mirsky Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: Re: Adoption of draft-vkst-bfd-mpls-mib On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote: > Dear Chairs, Authors, et al., > I think that this is needed work but the document needs some modification= s: > - read-create objects can be modified into read-only as no firm=20 > requirement to support SNMP based configuration can be found; Are you asking us to specifically make the MIB read-only? If so, this wou= ld be at least the second request recently (third if you include mine). Ho= wever, it might be good to get some guidance from the WG chairs on this dir= ection as making these changes can be potentially significant. --Tom > - bfdMplsSessTable lacks object to reflect whether Coordinated or=20 > Independent monitoring mode being used per RFC 6428; > - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS=20 > specific but is expression of local policy set by an operator. The=20 > bfdMplsSessTmrNegotiate should be removed from the bfdMplsSessTable=20 > table; > - list of modes for the bfdMplsSessMode object should include a mode,=20 > perhaps referred as bfd, which performs continuity check but does not=20 > support RDI functionality (RFC 5884 and RFC 5885); > - bfdMplsSessTable needs to reflect addressing used if=20 > bfdMplsSessMapType =3D mep(6) - IP or ICC; > - bfdMplsSessTable needs to reflect encapsulation type, IP or ACH/G-ACh, = being used. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Jeffrey Haas > Sent: Friday, June 01, 2012 8:13 AM > To: rtg-bfd@ietf.org > Subject: Adoption of draft-vkst-bfd-mpls-mib >=20 > Working Group, >=20 > This begins a one week poll for the adoption of=20 > http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib > as a working group document. >=20 > Note that this appears to be currently within the scope of our charter: >=20 > : 1. Develop the MIB module for BFD and submit it to the IESG for=20 > publication > : as a Proposed Standard.=20 > :=20 > : 5. Assist in the standardization of the BFD protocol for MPLS-TP.=20 > The > : preferred solution will be interoperable with the current BFD specifica= tion.=20 >=20 > If our ADs disagree, we'll ask for a formal charter change to pick up thi= s item. >=20 > The room discussion regarding this draft during IETF 83 was positive. >=20 > -- Jeff >=20 From jhaas@slice.pfrc.org Wed Jun 6 10:40:25 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD8121F86C3 for ; Wed, 6 Jun 2012 10:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F-62POKPD6k for ; Wed, 6 Jun 2012 10:40:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BCAB721F8598 for ; Wed, 6 Jun 2012 10:40:24 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id EA86CD19D; Wed, 6 Jun 2012 13:40:12 -0400 (EDT) Date: Wed, 6 Jun 2012 13:40:12 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD on LAGs - 04 published Message-ID: <20120606174012.GA13679@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2012 17:40:25 -0000 Working Group, I'm still waiting for the I-D publication notice to work its way through the system, but the latest version of BFD over LAGs is available for comment: http://tools.ietf.org/html/draft-mmm-bfd-on-lags-04 This version of the draft reflects the various comments we've had to this point and in particular attempts to address the IEEE concerns with the draft. At this point, the draft appears to be rapdily converging on stability. There is still time for a -05 to be issued prior to the upcoming IETF session to reflect further discussion. The authors and editors would thus like to invite comment on the draft. It is my expectation that even if the implementation details for the BFD over LAG mechanism are likely to change that our normative requirements on LACP will *not* change. I'd like to request for expedited review from the WG to review the draft, in particular for the normative requirements on LACP. This is so that we can issue our response to IEEE. I'd like to suggest a one week review period prior to the IEEE response. -- Jeff From jhaas@slice.pfrc.org Wed Jun 6 11:23:06 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7588111E8086 for ; Wed, 6 Jun 2012 11:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4BHz01Bo3bE for ; Wed, 6 Jun 2012 11:23:05 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 966EA21F8869 for ; Wed, 6 Jun 2012 11:23:05 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B7D5D0F3; Wed, 6 Jun 2012 14:23:04 -0400 (EDT) Date: Wed, 6 Jun 2012 14:23:04 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org, Gregory Mirsky , Thomas Nadeau , "mpls-chairs@tools.ietf.org" Subject: Re: Fwd: Adoption of draft-vkst-bfd-mpls-mib Message-ID: <20120606182304.GD13679@pfrc> References: <4FCEC28B.50207@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2012 18:23:06 -0000 Loa had forwarded the following response that was partially posted: > Begin forwarded message: > > > From: Loa Andersson > > Subject: Re: Adoption of draft-vkst-bfd-mpls-mib > > Date: June 5, 2012 10:38:03 PM EDT > > To: Gregory Mirsky > > Cc: Thomas Nadeau , "mpls-chairs@tools.ietf.org" , Jeff Haas , David Ward > > > > hmmm tried to figure out the bfd chairs alias, but have yo give up > > > > /Loq > > > > On 2012-06-06 04:30, Loa Andersson wrote: > >> resend with what i hope is the correct address > >> > >> > >> On 2012-06-06 04:28, Loa Andersson wrote: > >>> > >>> Folks, > >>> > >>> this is intended to be a rtg-bfd document, isn't it? If so the guidance > >>> should from the from the rtg-bfd chairs. > >>> > >>> mpls chairs will support and help with reviews. > >>> > >>> My experience aldo tells me that it is a good idea to eep the > >>> mib-doctors in the loop. Question: Do we have a responsibility to ITU to provide configuration MIBs for MPLS-TP? If so, since a MPLS-TP BFD MIB would build on a BFD MIB, we would need to keep read-write. As has been mentioned elsewhere in this thread, it sounds like there may be consumers of BFD read-create objects already. As much as I tend to agree with Tom and company that writeable MIBs are a bad idea, we may be stuck with it. That said, bfdModuleReadOnlyCompliance, documents a read-only conformance for the MIB. It is thus possible to implement this MIB without permitting configuration. -- Jeff > >>> > >>> /Loa > >>> > >>> On 2012-06-06 02:42, Gregory Mirsky wrote: > >>>> Hi Tom, > >>>> yes, you can count me in. As for "guidance from the WG chairs", Which > >>>> working group should provide such guidance - RTG-BFD or MPLS? > >>>> > >>>> Regards, > >>>> Greg > >>>> > >>>> -----Original Message----- > >>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] > >>>> Sent: Tuesday, June 05, 2012 4:55 PM > >>>> To: Gregory Mirsky > >>>> Cc: Jeffrey Haas; rtg-bfd@ietf.org > >>>> Subject: Re: Adoption of draft-vkst-bfd-mpls-mib > >>>> > >>>> > >>>> On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote: > >>>> > >>>>> Dear Chairs, Authors, et al., > >>>>> I think that this is needed work but the document needs some > >>>>> modifications: > >>>>> - read-create objects can be modified into read-only as no firm > >>>>> requirement to support SNMP based configuration can be found; > >>>> > >>>> Are you asking us to specifically make the MIB read-only? If so, this > >>>> would be at least the second request recently (third if you include > >>>> mine). However, it might be good to get some guidance from the WG > >>>> chairs on this direction as making these changes can be potentially > >>>> significant. > >>>> > >>>> --Tom > >>>> > >>>> > >>>>> - bfdMplsSessTable lacks object to reflect whether Coordinated or > >>>>> Independent monitoring mode being used per RFC 6428; > >>>>> - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS > >>>>> specific but is expression of local policy set by an operator. The > >>>>> bfdMplsSessTmrNegotiate should be removed from the bfdMplsSessTable > >>>>> table; > >>>>> - list of modes for the bfdMplsSessMode object should include a mode, > >>>>> perhaps referred as bfd, which performs continuity check but does not > >>>>> support RDI functionality (RFC 5884 and RFC 5885); > >>>>> - bfdMplsSessTable needs to reflect addressing used if > >>>>> bfdMplsSessMapType = mep(6) - IP or ICC; > >>>>> - bfdMplsSessTable needs to reflect encapsulation type, IP or > >>>>> ACH/G-ACh, being used. > >>>>> > >>>>> Regards, > >>>>> Greg > >>>>> > >>>>> -----Original Message----- > >>>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > >>>>> Behalf Of Jeffrey Haas > >>>>> Sent: Friday, June 01, 2012 8:13 AM > >>>>> To: rtg-bfd@ietf.org > >>>>> Subject: Adoption of draft-vkst-bfd-mpls-mib > >>>>> > >>>>> Working Group, > >>>>> > >>>>> This begins a one week poll for the adoption of > >>>>> http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib > >>>>> as a working group document. > >>>>> > >>>>> Note that this appears to be currently within the scope of our charter: > >>>>> > >>>>> : 1. Develop the MIB module for BFD and submit it to the IESG for > >>>>> publication > >>>>> : as a Proposed Standard. > >>>>> : > >>>>> : 5. Assist in the standardization of the BFD protocol for MPLS-TP. > >>>>> The > >>>>> : preferred solution will be interoperable with the current BFD > >>>>> specification. > >>>>> > >>>>> If our ADs disagree, we'll ask for a formal charter change to pick up > >>>>> this item. > >>>>> > >>>>> The room discussion regarding this draft during IETF 83 was positive. > >>>>> > >>>>> -- Jeff > >>>>> > >>>> > >>> > >> > > > > -- > > > > > > Loa Andersson email: loa.andersson@ericsson.com > > Sr Strategy and Standards Manager loa@pi.nu > > Ericsson Inc phone: +46 10 717 52 13 > > +46 767 72 92 13 > From loa@pi.nu Wed Jun 6 18:12:58 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2311E80A5 for ; Wed, 6 Jun 2012 18:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcKkVSusExa7 for ; Wed, 6 Jun 2012 18:12:58 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 3868011E8087 for ; Wed, 6 Jun 2012 18:12:57 -0700 (PDT) Received: from [172.16.36.55] (unknown [122.146.68.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id F164D2A8002; Thu, 7 Jun 2012 03:12:50 +0200 (CEST) Message-ID: <4FD0000C.30405@pi.nu> Date: Thu, 07 Jun 2012 03:12:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jeffrey Haas Subject: Re: Fwd: Adoption of draft-vkst-bfd-mpls-mib References: <4FCEC28B.50207@pi.nu> <20120606182304.GD13679@pfrc> In-Reply-To: <20120606182304.GD13679@pfrc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-ads@tools.ietf.org" , Benoit Claise , rtg-bfd@ietf.org, "mpls-chairs@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2012 01:12:59 -0000 Jeff, thanks for forwarding. The question whether we have a responsibility to *ITU-T* to provide configuration MIBs for MPLS-TP is "interesting"! Currently there is no explicit agreement on MPLS-TP deliverables between IETF and ITU-T, the JWT agreement has dated. However there are certain rules of conduct that governs the relationship between two peer SDOs. This include for example that we liaise and respond to liaisons when we see an interest in both organizations. This means that we for example copy all wg last calls on MPLS-TP documents to the Ad Hoc Team mailing list. I am not aware of any interest expressed by ITU-T for configuration MIBs, but on the other hand there is a clear interest from a number of operators for such MIBs. In my mind this would be the reason to keep the read-write. However I'd lkie our OPS and RTG ADs opinion on this. /Loa On 2012-06-06 20:23, Jeffrey Haas wrote: > Loa had forwarded the following response that was partially posted: > >> Begin forwarded message: >> >>> From: Loa Andersson >>> Subject: Re: Adoption of draft-vkst-bfd-mpls-mib >>> Date: June 5, 2012 10:38:03 PM EDT >>> To: Gregory Mirsky >>> Cc: Thomas Nadeau, "mpls-chairs@tools.ietf.org", Jeff Haas, David Ward >>> >>> hmmm tried to figure out the bfd chairs alias, but have yo give up >>> >>> /Loa >>> >>> On 2012-06-06 04:30, Loa Andersson wrote: >>>> resend with what i hope is the correct address >>>> >>>> >>>> On 2012-06-06 04:28, Loa Andersson wrote: >>>>> >>>>> Folks, >>>>> >>>>> this is intended to be a rtg-bfd document, isn't it? If so the guidance >>>>> should from the from the rtg-bfd chairs. >>>>> >>>>> mpls chairs will support and help with reviews. >>>>> >>>>> My experience aldo tells me that it is a good idea to eep the >>>>> mib-doctors in the loop. > > Question: Do we have a responsibility to ITU to provide configuration MIBs > for MPLS-TP? If so, since a MPLS-TP BFD MIB would build on a BFD MIB, we > would need to keep read-write. > > As has been mentioned elsewhere in this thread, it sounds like there may be > consumers of BFD read-create objects already. As much as I tend to agree > with Tom and company that writeable MIBs are a bad idea, we may be stuck > with it. > > That said, bfdModuleReadOnlyCompliance, documents a read-only conformance > for the MIB. It is thus possible to implement this MIB without permitting > configuration. > > -- Jeff > >>>>> >>>>> /Loa >>>>> >>>>> On 2012-06-06 02:42, Gregory Mirsky wrote: >>>>>> Hi Tom, >>>>>> yes, you can count me in. As for "guidance from the WG chairs", Which >>>>>> working group should provide such guidance - RTG-BFD or MPLS? >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> -----Original Message----- >>>>>> From: Thomas Nadeau [mailto:tnadeau@lucidvision.com] >>>>>> Sent: Tuesday, June 05, 2012 4:55 PM >>>>>> To: Gregory Mirsky >>>>>> Cc: Jeffrey Haas; rtg-bfd@ietf.org >>>>>> Subject: Re: Adoption of draft-vkst-bfd-mpls-mib >>>>>> >>>>>> >>>>>> On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote: >>>>>> >>>>>>> Dear Chairs, Authors, et al., >>>>>>> I think that this is needed work but the document needs some >>>>>>> modifications: >>>>>>> - read-create objects can be modified into read-only as no firm >>>>>>> requirement to support SNMP based configuration can be found; >>>>>> >>>>>> Are you asking us to specifically make the MIB read-only? If so, this >>>>>> would be at least the second request recently (third if you include >>>>>> mine). However, it might be good to get some guidance from the WG >>>>>> chairs on this direction as making these changes can be potentially >>>>>> significant. >>>>>> >>>>>> --Tom >>>>>> >>>>>> >>>>>>> - bfdMplsSessTable lacks object to reflect whether Coordinated or >>>>>>> Independent monitoring mode being used per RFC 6428; >>>>>>> - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS >>>>>>> specific but is expression of local policy set by an operator. The >>>>>>> bfdMplsSessTmrNegotiate should be removed from the bfdMplsSessTable >>>>>>> table; >>>>>>> - list of modes for the bfdMplsSessMode object should include a mode, >>>>>>> perhaps referred as bfd, which performs continuity check but does not >>>>>>> support RDI functionality (RFC 5884 and RFC 5885); >>>>>>> - bfdMplsSessTable needs to reflect addressing used if >>>>>>> bfdMplsSessMapType = mep(6) - IP or ICC; >>>>>>> - bfdMplsSessTable needs to reflect encapsulation type, IP or >>>>>>> ACH/G-ACh, being used. >>>>>>> >>>>>>> Regards, >>>>>>> Greg >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >>>>>>> Behalf Of Jeffrey Haas >>>>>>> Sent: Friday, June 01, 2012 8:13 AM >>>>>>> To: rtg-bfd@ietf.org >>>>>>> Subject: Adoption of draft-vkst-bfd-mpls-mib >>>>>>> >>>>>>> Working Group, >>>>>>> >>>>>>> This begins a one week poll for the adoption of >>>>>>> http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib >>>>>>> as a working group document. >>>>>>> >>>>>>> Note that this appears to be currently within the scope of our charter: >>>>>>> >>>>>>> : 1. Develop the MIB module for BFD and submit it to the IESG for >>>>>>> publication >>>>>>> : as a Proposed Standard. >>>>>>> : >>>>>>> : 5. Assist in the standardization of the BFD protocol for MPLS-TP. >>>>>>> The >>>>>>> : preferred solution will be interoperable with the current BFD >>>>>>> specification. >>>>>>> >>>>>>> If our ADs disagree, we'll ask for a formal charter change to pick up >>>>>>> this item. >>>>>>> >>>>>>> The room discussion regarding this draft during IETF 83 was positive. >>>>>>> >>>>>>> -- Jeff >>>>>>> >>>>>> >>>>> >>>> >>> >>> -- >>> >>> >>> Loa Andersson email: loa.andersson@ericsson.com >>> Sr Strategy and Standards Manager loa@pi.nu >>> Ericsson Inc phone: +46 10 717 52 13 >>> +46 767 72 92 13 >> -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From internet-drafts@ietf.org Thu Jun 7 05:23:14 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8095821F885D; Thu, 7 Jun 2012 05:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e386oHF6sT+A; Thu, 7 Jun 2012 05:23:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C867521F87E1; Thu, 7 Jun 2012 05:23:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-generic-crypto-auth-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120607122313.29663.13201.idtracker@ietfa.amsl.com> Date: Thu, 07 Jun 2012 05:23:13 -0700 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 07 Jun 2012 12:23:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Wo= rking Group of the IETF. Title : BFD Generic Cryptographic Authentication Author(s) : Manav Bhatia Vishwas Manral Dacheng Zhang Filename : draft-ietf-bfd-generic-crypto-auth-02.txt Pages : 12 Date : 2012-06-07 This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure that is required for supporting algorithm and key agility for BFD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-crypto-auth-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bfd-generic-crypto-auth-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-generic-crypto-auth/ From internet-drafts@ietf.org Thu Jun 14 06:44:56 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7021F86BB; Thu, 14 Jun 2012 06:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Oe3kfeJX3T1; Thu, 14 Jun 2012 06:44:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125CC21F86AD; Thu, 14 Jun 2012 06:44:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-tc-mib-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120614134456.26531.56268.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2012 06:44:56 -0700 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 13:44:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Definitions of Textual Conventions (TCs) for Bidirection= al Forwarding Detection (BFD) Management Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-tc-mib-01.txt Pages : 10 Date : 2012-06-14 Abstract: This draft defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Bidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-tc-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-tc-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Jun 15 12:15:23 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DD611E80D5; Fri, 15 Jun 2012 12:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T5hO+s+YbyS; Fri, 15 Jun 2012 12:15:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3A211E80D0; Fri, 15 Jun 2012 12:15:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mib-11.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120615191522.7305.68565.idtracker@ietfa.amsl.com> Date: Fri, 15 Jun 2012 12:15:22 -0700 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2012 19:15:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base Author(s) : Thomas D. Nadeau Zafar Ali Nobo Akiya Filename : draft-ietf-bfd-mib-11.txt Pages : 38 Date : 2012-06-15 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mib-11 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mib-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From muly_i@rad.com Sun Jun 17 09:28:15 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BD321F85CC for ; Sun, 17 Jun 2012 09:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GoR-1zMcns2 for ; Sun, 17 Jun 2012 09:28:14 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEA421F85C6 for ; Sun, 17 Jun 2012 09:28:13 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 17 Jun 2012 19:09:19 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Sun, 17 Jun 2012 19:28:10 +0300 From: Muly Ilan To: "rtg-bfd@ietf.org" Subject: Comments on draft-ietf-bfd-mib-11 Thread-Topic: Comments on draft-ietf-bfd-mib-11 Thread-Index: Ac1Mpi7QP7rHa8SMSk2A6FYk8Vl+bQ== Date: Sun, 17 Jun 2012 16:28:10 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87042C2814@EXRAD5.ad.rad.co.il> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.136] Content-Type: multipart/alternative; boundary="_000_32CB7A1F0806AB4688CE3F22C29DAC87042C2814EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090205.4FDE059B.00AA,ss=1,fgs=0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 17 Jun 2012 16:28:15 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC87042C2814EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Some of the description amendments done in this version of the document see= m like a mistake. 1. The definition of bfdSessPerfCtrlPktInHC is recursive. bfdSessPerfCtrlPktInHC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the total number of BFD control messages received for this BFD session. It MUST be equal to the least significant 32 bits of bfdSessPerfCtrlPktInHC if supported, and MUST do so the rules spelled out in RFC 2863." ::=3D { bfdSessPerfEntry 14 } 2. The description of all the HC counters is wrong. It now states tha= t the value of the HC counter (64 bit) must be equal to the value of the re= gular counter (32 bit) ??? An example problematic description: bfdSessPerfCtrlPktOutHC OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "This value represents the total number of BFD control messages transmitted for this BFD session. It MUST be equal to the least significant 32 bits of bfdSessPerfCtrlPktOut if supported, and MUST do so the rules spelled out in RFC 2863." ::=3D { bfdSessPerfEntry 15 } Muly --_000_32CB7A1F0806AB4688CE3F22C29DAC87042C2814EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Some of the description amendments done in this vers= ion of the document seem like a mistake.

 

1.     &= nbsp; The definition of bfdSessP= erfCtrlPktInHC is recursive.

 

bfdSessPerfCtrlPktInHC OBJECT-TYPE

        SYNTAX&nb= sp;    Counter64

        MAX-ACCES= S read-only

        STATUS&nb= sp;    current

        DESCRIPTI= ON

        &nbs= p;   "This value represents the total number of BFD control<= o:p>

        &nbs= p;    messages received for this BFD session.

 

        &nbs= p;    It MUST be equal to the least significant 32 bits of

        &nbs= p;    bfdSessPerfCtrlPktInHC if supported, and MUST do so

        &nbs= p;    the rules spelled out in RFC 2863."

        ::=3D { b= fdSessPerfEntry 14 }

 

 

2.     &= nbsp; The description of all the= HC counters is wrong. It now states that the value of the HC counter (64 b= it) must be equal to the value of the regular counter (32 bit) ???

 

An example problematic description:

    bfdSessPerfCtrlPktOutHC OBJECT-TY= PE

        SYNTAX&nb= sp;    Counter64

        MAX-ACCES= S read-only

        STATUS&nb= sp;    current

        DESCRIPTI= ON

        &nbs= p;   "This value represents the total number of BFD control<= o:p>

        &nbs= p;    messages transmitted for this BFD session.<= /p>

 

        &nbs= p;    It MUST be equal to the leas= t significant 32 bits of

    &n= bsp;        bfdSessPerfCtrlPktOut if sup= ported, and MUST do so

    &n= bsp;        the rules spelled out in RFC= 2863."

        ::=3D { b= fdSessPerfEntry 15 }

 

 

Muly

--_000_32CB7A1F0806AB4688CE3F22C29DAC87042C2814EXRAD5adradcoil_-- From d3e3e3@gmail.com Tue Jun 19 20:17:45 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373911E8144 for ; Tue, 19 Jun 2012 20:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ84hFXwHjrH for ; Tue, 19 Jun 2012 20:17:45 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B15A411E80D2 for ; Tue, 19 Jun 2012 20:17:41 -0700 (PDT) Received: by yhq56 with SMTP id 56so5980597yhq.31 for ; Tue, 19 Jun 2012 20:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=kBpq1Pi2Wfru4JjERP8mxM2iyx7vBNqDrY6e2hs1220=; b=M6CKBlTYd+ZtWfl7IUOd2Uq0tmxwlab5PfYWPSprhXjRI9Dejp33g6JR4DqvGv+x+9 d/fwMDsxyQiYJNQtWixTGFemqrLr9haYKYrlZ4fwg9jlD7IxoyiLg6SgjlHgCeqnL8jR MYyVrue4BCN10NFsBRHsyugrqODpfJddOfOtBT59RBITFeULaKLYBzIr+qvJCPlwuhM/ UPbwfxX39KRhGby10SCSDQUBF6dlE/7ybHib8RTMjPwrYl7BTrwbJG5Drh6HZRKpMKeA /VYMCOtKp3vgxWe6x3htIXBvkq2PjJ7++1i6ennlrnwulVUyz6Nf8SLWlgaGvd3XOVk1 SvGQ== Received: by 10.50.34.200 with SMTP id b8mr3175370igj.50.1340162260912; Tue, 19 Jun 2012 20:17:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Tue, 19 Jun 2012 20:17:20 -0700 (PDT) From: Donald Eastlake Date: Tue, 19 Jun 2012 23:17:20 -0400 Message-ID: Subject: How widely used in BFD Authentication? To: rtg-bfd WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2012 03:17:45 -0000 H, Does anyone have a comment on how widely used BFD Authentication is, particularly the meticulous variety? Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From binnyjeshan@gmail.com Tue Jun 19 20:38:00 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CAB11E811A for ; Tue, 19 Jun 2012 20:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seo44X7eiQdB for ; Tue, 19 Jun 2012 20:37:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2BFB11E80D2 for ; Tue, 19 Jun 2012 20:37:58 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so14787lbb.31 for ; Tue, 19 Jun 2012 20:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m/RxwN/COW8occvMzbW4MuzVX3nWsx3oBmTymvxt3jU=; b=khbEjEn+imBoRlKwWAyJkmFLkfy4bCHnvf6BLabTysChgQyZRC0nnzYLQQbLdtcpc/ gpYMwt8FDevGnDrEiuCvn/6y8sPe1L9Ucrtb6KX/b4VORoXSUKPQNwlAclB6E84aKnwo 5ef4FrkGEx+LwOuQR4Myq2RjTlP4yXgLGpNGtMSum4/wrOIQSpwVdDm0YhvoOW71mMHz FtbNRzor1sLLiz3+H4VScVTZpNl6Aq396k8IxUVKVqWSb5jhvQgMW+yIjnuoWbgOyY64 RSGr9mVfs6TgIxv4E7PYBlml4aLBsPD/RItLimwHKORyEs8k8TpZK8sdP5NqmZQBNBkn fAdA== MIME-Version: 1.0 Received: by 10.152.144.168 with SMTP id sn8mr20747042lab.1.1340163477900; Tue, 19 Jun 2012 20:37:57 -0700 (PDT) Received: by 10.114.0.194 with HTTP; Tue, 19 Jun 2012 20:37:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Jun 2012 09:07:57 +0530 Message-ID: Subject: Re: How widely used in BFD Authentication? From: Binny Jeshan To: Donald Eastlake Content-Type: multipart/alternative; boundary=e89a8f2346870a8d7604c2df2004 Cc: rtg-bfd WG X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2012 03:38:00 -0000 --e89a8f2346870a8d7604c2df2004 Content-Type: text/plain; charset=ISO-8859-1 Good question. May be someone who is deploying it on the wire should answer. @ Donald - Do you refer its use in MPLS-TP or other networks? -Binny. On 20 June 2012 08:47, Donald Eastlake wrote: > H, > > Does anyone have a comment on how widely used BFD Authentication is, > particularly the meticulous variety? > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > --e89a8f2346870a8d7604c2df2004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good question. May be someone who is deploying it on the wire should answer= .

@ Donald - Do you refer its use in MPLS-TP or other ne= tworks?

-Binny.

On 20 June 2012 08:47, Donald Eastlake <d3e3e3@gmail.com> wro= te:
H,

Does anyone have a comment on how widely used BFD Authentication is,
particularly the meticulous variety?

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
=A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell)
=A0155 Beaver Street,=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com

--e89a8f2346870a8d7604c2df2004-- From gregimirsky@gmail.com Thu Jun 21 17:05:27 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1045121F8569 for ; Thu, 21 Jun 2012 17:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFAmOVVJTkjd for ; Thu, 21 Jun 2012 17:05:26 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3F21F855E for ; Thu, 21 Jun 2012 17:05:26 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1210590ggn.31 for ; Thu, 21 Jun 2012 17:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZOxlin1u04QDNBF5vtRR3vACbOu8B/kd/8AII/Ar3Ms=; b=sRIwEeCC2YthempV2larSl+vWbki95G9wFmOSgwYbs4osIcBi7KxMQLdHfZofc2l1p 3fPjBg9PrgLGk1KLjbO8cxEBqqDgbmO9J35THvBIy/kYsDHJT9ZgnK49A5cYDuU0kmdB HgiMSLgqsN4y0mBLapCjYTOukjrNdvDOc/XCGzrYV4fFhCySPFjva0teogJ40qFs43aP JtcdEQa9UmesOxWPgh3dO001i8pFB+o3TtATdB2gTLY9O3j84tZuqobcyRycO4nsx3n2 rINs6yjlQzZa7B/ZzyFJ8CY+bQzmKQ5pVBY6TT2UEDBA2Fp60YuVaFDarpP+sBW3duZR oBxQ== MIME-Version: 1.0 Received: by 10.60.2.131 with SMTP id 3mr2737oeu.59.1340323525730; Thu, 21 Jun 2012 17:05:25 -0700 (PDT) Received: by 10.182.71.167 with HTTP; Thu, 21 Jun 2012 17:05:25 -0700 (PDT) In-Reply-To: <20120606174012.GA13679@pfrc> References: <20120606174012.GA13679@pfrc> Date: Thu, 21 Jun 2012 17:05:25 -0700 Message-ID: Subject: Re: BFD on LAGs - 04 published From: Greg Mirsky To: Jeffrey Haas Content-Type: multipart/alternative; boundary=e89a8f643d9aa29fee04c304632b Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 22 Jun 2012 00:05:27 -0000 --e89a8f643d9aa29fee04c304632b Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, Editors, et al., I have one rather terminology note to the document: - Introduction. "The goal is to verify link connectivity for every member link." I believe that BFD as per RFC 5080 verifies continuity, not connectivity. If it was the latter, then there should be definitions of mis-connectivity defects, i.e. as in RFC 6428. Yes, the RFC 5080 refers to connectivity check, not to continuity check but, IMHO, clear terminology helps and perhaps we need to get these definitions clarified and use them properly. Regards, Greg On Wed, Jun 6, 2012 at 10:40 AM, Jeffrey Haas wrote: > Working Group, > > I'm still waiting for the I-D publication notice to work its way through > the > system, but the latest version of BFD over LAGs is available for comment: > > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-04 > > This version of the draft reflects the various comments we've had to this > point and in particular attempts to address the IEEE concerns with the > draft. > > At this point, the draft appears to be rapdily converging on stability. > There is still time for a -05 to be issued prior to the upcoming IETF > session to reflect further discussion. The authors and editors would thus > like to invite comment on the draft. > > It is my expectation that even if the implementation details for the BFD > over LAG mechanism are likely to change that our normative requirements on > LACP will *not* change. > > I'd like to request for expedited review from the WG to review the draft, > in > particular for the normative requirements on LACP. This is so that we can > issue our response to IEEE. > > I'd like to suggest a one week review period prior to the IEEE response. > > -- Jeff > --e89a8f643d9aa29fee04c304632b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors, Editors, et al.,
I have one rather terminology note to the= document:
  • Introduction. "The goal is to verify link connec= tivity for every member link." I believe that BFD as per RFC 5080 veri= fies continuity, not connectivity. If it was the latter, then there should = be definitions of mis-connectivity defects, i.e. as in RFC 6428. Yes, the R= FC 5080 refers to connectivity check, not to continuity check but, IMHO, cl= ear terminology helps and perhaps we need to get these definitions clarifie= d and use them properly.
Regards,
Greg

On Wed, Jun 6, 2012= at 10:40 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Working Group,

I'm still waiting for the I-D publication notice to work its way throug= h the
system, but the latest version of BFD over LAGs is available for comment:
http://tools.ietf.org/html/draft-mmm-bfd-on-lags-04

This version of the draft reflects the various comments we've had to th= is
point and in particular attempts to address the IEEE concerns with the
draft.

At this point, the draft appears to be rapdily converging on stability.
There is still time for a -05 to be issued prior to the upcoming IETF
session to reflect further discussion. =A0The authors and editors would thu= s
like to invite comment on the draft.

It is my expectation that even if the implementation details for the BFD over LAG mechanism are likely to change that our normative requirements on<= br> LACP will *not* change.

I'd like to request for expedited review from the WG to review the draf= t, in
particular for the normative requirements on LACP. =A0This is so that we ca= n
issue our response to IEEE.

I'd like to suggest a one week review period prior to the IEEE response= .

-- Jeff

--e89a8f643d9aa29fee04c304632b-- From yael@compass-eos.com Mon Jun 25 06:31:33 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BC821F8637 for ; Mon, 25 Jun 2012 06:31:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYatM5yLrSUt for ; Mon, 25 Jun 2012 06:31:28 -0700 (PDT) Received: from email.compass-eos.com (email.compass-eos.com [91.212.114.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2521F8630 for ; Mon, 25 Jun 2012 06:31:27 -0700 (PDT) Received: from CMP-EX-DB2.cmpsys.com ([::1]) by cmp-ex-cas1.cmpsys.com ([::1]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 16:31:25 +0300 From: Yael Frank Dayan To: "rtg-bfd@ietf.org" Subject: RE: BFD on LAGs - 04 published Thread-Topic: BFD on LAGs - 04 published Thread-Index: AQHNRAtxR5j7rxlBVUGMXd2mBIvuK5cFWxCAgAXHCXA= Date: Mon, 25 Jun 2012 13:31:24 +0000 Message-ID: <70A1AFC4870DD34181EF6783D7DAF691056BCA09@CMP-EX-DB2.cmpsys.com> References: <20120606174012.GA13679@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.30.8] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2012 13:31:33 -0000 Hi, I think the following needs clarification: "Control packets use a destination IP address that is the peer's remote IP = address." The term 'peer's remote IP address' is not specific enough. Do you mean the= IP address assigned to the aggregated interface? Thanks, Yael From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Greg Mirsky Sent: Friday, June 22, 2012 3:05 AM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAGs - 04 published Dear Authors, Editors, et al., I have one rather terminology note to the document: . Introduction. "The goal is to verify link connectivity for every member l= ink." I believe that BFD as per RFC 5080 verifies continuity, not connectiv= ity. If it was the latter, then there should be definitions of mis-connecti= vity defects, i.e. as in RFC 6428. Yes, the RFC 5080 refers to connectivity= check, not to continuity check but, IMHO, clear terminology helps and perh= aps we need to get these definitions clarified and use them properly. Regards, Greg On Wed, Jun 6, 2012 at 10:40 AM, Jeffrey Haas wrote: Working Group, I'm still waiting for the I-D publication notice to work its way through th= e system, but the latest version of BFD over LAGs is available for comment: http://tools.ietf.org/html/draft-mmm-bfd-on-lags-04 This version of the draft reflects the various comments we've had to this point and in particular attempts to address the IEEE concerns with the draft. At this point, the draft appears to be rapdily converging on stability. There is still time for a -05 to be issued prior to the upcoming IETF session to reflect further discussion. =A0The authors and editors would thu= s like to invite comment on the draft. It is my expectation that even if the implementation details for the BFD over LAG mechanism are likely to change that our normative requirements on LACP will *not* change. I'd like to request for expedited review from the WG to review the draft, i= n particular for the normative requirements on LACP. =A0This is so that we ca= n issue our response to IEEE. I'd like to suggest a one week review period prior to the IEEE response. -- Jeff From manav.bhatia@alcatel-lucent.com Mon Jun 25 16:24:12 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCE411E808F for ; Mon, 25 Jun 2012 16:24:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QQD-9jnhXFr for ; Mon, 25 Jun 2012 16:24:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFBC11E808C for ; Mon, 25 Jun 2012 16:24:11 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q5PNO461000571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jun 2012 18:24:06 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q5PNO23m015340 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Jun 2012 04:54:03 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 26 Jun 2012 04:54:02 +0530 From: "Bhatia, Manav (Manav)" To: Yael Frank Dayan , "rtg-bfd@ietf.org" Date: Tue, 26 Jun 2012 04:54:12 +0530 Subject: RE: BFD on LAGs - 04 published Thread-Topic: BFD on LAGs - 04 published Thread-Index: AQHNRAtxR5j7rxlBVUGMXd2mBIvuK5cFWxCAgAXHCXCAAKj6QA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0604AD11@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20120606174012.GA13679@pfrc> <70A1AFC4870DD34181EF6783D7DAF691056BCA09@CMP-EX-DB2.cmpsys.com> In-Reply-To: <70A1AFC4870DD34181EF6783D7DAF691056BCA09@CMP-EX-DB2.cmpsys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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, 25 Jun 2012 23:24:12 -0000 Yes, that's what it means. Cheers, Manav=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Yael Frank Dayan > Sent: Monday, June 25, 2012 7:01 PM > To: rtg-bfd@ietf.org > Subject: RE: BFD on LAGs - 04 published >=20 > Hi, > I think the following needs clarification: > "Control packets use a destination IP address that is the=20 > peer's remote IP address." > The term 'peer's remote IP address' is not specific enough.=20 > Do you mean the IP address assigned to the aggregated interface? > Thanks, > Yael >=20 >=20 > From: rtg-bfd-bounces@ietf.org=20 > [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Greg Mirsky > Sent: Friday, June 22, 2012 3:05 AM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAGs - 04 published >=20 > Dear Authors, Editors, et al., > I have one rather terminology note to the document: > . Introduction. "The goal is to verify link connectivity for=20 > every member link." I believe that BFD as per RFC 5080=20 > verifies continuity, not connectivity. If it was the latter,=20 > then there should be definitions of mis-connectivity defects,=20 > i.e. as in RFC 6428. Yes, the RFC 5080 refers to connectivity=20 > check, not to continuity check but, IMHO, clear terminology=20 > helps and perhaps we need to get these definitions clarified=20 > and use them properly. > Regards, > Greg > On Wed, Jun 6, 2012 at 10:40 AM, Jeffrey Haas wrote: > Working Group, >=20 > I'm still waiting for the I-D publication notice to work its=20 > way through the system, but the latest version of BFD over=20 > LAGs is available for comment: >=20 > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-04 >=20 > This version of the draft reflects the various comments we've=20 > had to this point and in particular attempts to address the=20 > IEEE concerns with the draft. >=20 > At this point, the draft appears to be rapdily converging on=20 > stability. > There is still time for a -05 to be issued prior to the=20 > upcoming IETF session to reflect further discussion. =A0The=20 > authors and editors would thus like to invite comment on the draft. >=20 > It is my expectation that even if the implementation details=20 > for the BFD over LAG mechanism are likely to change that our=20 > normative requirements on LACP will *not* change. >=20 > I'd like to request for expedited review from the WG to=20 > review the draft, in particular for the normative=20 > requirements on LACP. =A0This is so that we can issue our=20 > response to IEEE. >=20 > I'd like to suggest a one week review period prior to the=20 > IEEE response. >=20 > -- Jeff >=20 > = From jhaas@slice.pfrc.org Wed Jun 27 07:28:23 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1421F87B7 for ; Wed, 27 Jun 2012 07:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXDvAHLeIOtj for ; Wed, 27 Jun 2012 07:28:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0336121F87B6 for ; Wed, 27 Jun 2012 07:28:23 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 77B4FD0F2; Wed, 27 Jun 2012 10:28:22 -0400 (EDT) Date: Wed, 27 Jun 2012 10:28:22 -0400 From: Jeffrey Haas To: Sam Aldrin Subject: Re: Adoption of draft-vkst-bfd-mpls-mib Message-ID: <20120627142822.GE18361@pfrc> References: <20120601151238.GV4067@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 14:28:23 -0000 Sam, On Tue, Jun 05, 2012 at 05:35:37PM -0700, Sam Aldrin wrote: > We were asked specifically by the WG chairs, in the Paris WG session, to add read write option to the MIB. AD and MPLS WG chair also provided their comments and felt BFD MIB extension to support TP should have write support. This was under the presumption that we needed to provide this as part of our MPLS-TP agreement with ITU. After consulting with the MPLS chairs (or at least, per Loa's answer) and our ADs, this doesn't appear to be the case. So, as a motivating factor, we don't need it. > There are at least three vendors who are requesting write support as well. *That* is far more interesting. Per other discussions off-list, I was considering polling the WG to see if we should consider removing the write profile for the MIBs. Would those three vendors be willing to go on record stating that they want write-access to the MIB? This wouldn't be a formal statement of "we'll support this in X version of our software", just "we want the option to be able to do SNMP SET in this MIB." Having some sort of public statement for this would help an upcoming OPS open-area meeting at the upcoming IETF in Vancouver with regard to this general topic. If the vendors aren't willing to publicly state this but are willing to privately do so, that would also be helpful. > To the original comment that there is no requirement for write support for MIB, my answer is, there is no requirement to have just read only either. If there is consensus that, write option shouldnt exist in MIBs, it should be stated so. Otherwise, the confusion will persist every time. In general, a read-only profile is desirable because there exists a set of vendors who have no intention to provide SNMP SET access to their MIB implementations. Without a supporting conformance statement, those vendors are not conformant. Obviously the protocol works just fine read-only, but it upsets the people who track such things in spreadsheets. :-) -- Jeff From muly_i@rad.com Wed Jun 27 07:49:30 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F94121F85E6 for ; Wed, 27 Jun 2012 07:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, SARE_SUB_OBFU_OTHER=0.135, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvB1g4V1N9Qm for ; Wed, 27 Jun 2012 07:49:29 -0700 (PDT) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id A5A1721F85E5 for ; Wed, 27 Jun 2012 07:49:26 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 27 Jun 2012 17:29:56 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Wed, 27 Jun 2012 17:49:23 +0300 From: Muly Ilan To: "rtg-bfd@ietf.org" Subject: RE: Adoption of draft-vkst-bfd-mpls-mib Thread-Topic: Adoption of draft-vkst-bfd-mpls-mib Thread-Index: AQHNVHEh49sZMUraLkecA5jIAlQv1pcOPboQ Date: Wed, 27 Jun 2012 14:49:23 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87042C6149@EXRAD5.ad.rad.co.il> References: <20120601151238.GV4067@pfrc> <20120627142822.GE18361@pfrc> In-Reply-To: <20120627142822.GE18361@pfrc> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.136] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0B0209.4FEB1D74.0068,ss=1,pt=DBB_65836,fgs=0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 14:49:30 -0000 Hi, We, at RAD, plan to support the write-access to this BFD extension MIB. Regards, Muly Ilan Senior System Architect, R&D T: +972-3-765-7035 | M: +972-54-470-1004 | F: +972-3-644-0930 =A0| muly_i@r= ad.com=20 RAD Data Communications Ltd. 24, Raoul Wallenberg=A0St. Tel-Aviv 69719, Isr= ael=A0=A0| www.rad.com -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Wednesday, June 27, 2012 5:28 PM To: Sam Aldrin Cc: rtg-bfd@ietf.org Subject: Re: Adoption of draft-vkst-bfd-mpls-mib Sam, On Tue, Jun 05, 2012 at 05:35:37PM -0700, Sam Aldrin wrote: > We were asked specifically by the WG chairs, in the Paris WG session, to = add read write option to the MIB. AD and MPLS WG chair also provided their = comments and felt BFD MIB extension to support TP should have write support= . This was under the presumption that we needed to provide this as part of ou= r MPLS-TP agreement with ITU. After consulting with the MPLS chairs (or at= least, per Loa's answer) and our ADs, this doesn't appear to be the case.= =20 So, as a motivating factor, we don't need it. > There are at least three vendors who are requesting write support as well= . *That* is far more interesting. Per other discussions off-list, I was cons= idering polling the WG to see if we should consider removing the write prof= ile for the MIBs. Would those three vendors be willing to go on record stating that they want= write-access to the MIB? This wouldn't be a formal statement of "we'll su= pport this in X version of our software", just "we want the option to be ab= le to do SNMP SET in this MIB." Having some sort of public statement for t= his would help an upcoming OPS open-area meeting at the upcoming IETF in Va= ncouver with regard to this general topic. If the vendors aren't willing to publicly state this but are willing to pri= vately do so, that would also be helpful. > To the original comment that there is no requirement for write support fo= r MIB, my answer is, there is no requirement to have just read only either.= If there is consensus that, write option shouldnt exist in MIBs, it should= be stated so. Otherwise, the confusion will persist every time. In general, a read-only profile is desirable because there exists a set of = vendors who have no intention to provide SNMP SET access to their MIB imple= mentations. Without a supporting conformance statement, those vendors are = not conformant. Obviously the protocol works just fine read-only, but it u= psets the people who track such things in spreadsheets. :-) -- Jeff From internet-drafts@ietf.org Wed Jun 27 08:20:10 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8747121F8778; Wed, 27 Jun 2012 08:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pflk1qPT5VaP; Wed, 27 Jun 2012 08:20:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A690D21F876C; Wed, 27 Jun 2012 08:20:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-multipoint-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120627152009.19255.72107.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 08:20:09 -0700 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 15:20:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD for Multipoint Networks Author(s) : Dave Katz Dave Ward Filename : draft-ietf-bfd-multipoint-01.txt Pages : 29 Date : 2012-06-01 Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg-bfd@ietf.org. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-multipoint-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-multipoint-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhaas@slice.pfrc.org Wed Jun 27 10:48:09 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347F911E8091 for ; Wed, 27 Jun 2012 10:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_OTHER=0.135, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy34aHux4a7Q for ; Wed, 27 Jun 2012 10:48:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37911E8073 for ; Wed, 27 Jun 2012 10:48:08 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 18331C6B7; Wed, 27 Jun 2012 13:48:07 -0400 (EDT) Date: Wed, 27 Jun 2012 13:48:07 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Adoption of draft-vkst-bfd-mpls-mib Message-ID: <20120627174806.GS18361@pfrc> References: <20120601151238.GV4067@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120601151238.GV4067@pfrc> User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 17:48:09 -0000 On Fri, Jun 01, 2012 at 11:12:38AM -0400, Jeffrey Haas wrote: > Working Group, > > This begins a one week poll for the adoption of > http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib > as a working group document. > > Note that this appears to be currently within the scope of our charter: > > : 1. Develop the MIB module for BFD and submit it to the IESG for publication > : as a Proposed Standard. > : > : 5. Assist in the standardization of the BFD protocol for MPLS-TP. The > : preferred solution will be interoperable with the current BFD specification. > > If our ADs disagree, we'll ask for a formal charter change to pick up this > item. > > The room discussion regarding this draft during IETF 83 was positive. There was no objection to adopting this draft as a WG item. Mailing list discussion suggests that we'll have some work to do on this. Authors, please submit this as draft-ietf-bfd-mpls-mib. -- Jeff From internet-drafts@ietf.org Wed Jun 27 11:29:24 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA2611E8130; Wed, 27 Jun 2012 11:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP-NejLr0+kP; Wed, 27 Jun 2012 11:29:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C595911E8116; Wed, 27 Jun 2012 11:29:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mpls-mib-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120627182923.24211.52847.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 11:29:23 -0700 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 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 Jun 2012 18:29:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base (MIB) extensions for MPL= S and MPLS-TP Networks Author(s) : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-bfd-mpls-mib-00.txt Pages : 19 Date : 2012-06-27 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/