From jhaas@slice.pfrc.org Mon Jul 2 12:57: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 7487111E80DC for ; Mon, 2 Jul 2012 12:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.027, 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 4ZmOHU903rsh for ; Mon, 2 Jul 2012 12:57:27 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 161CC11E80A3 for ; Mon, 2 Jul 2012 12:57:27 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 06BAFD1FB; Mon, 2 Jul 2012 15:57:32 -0400 (EDT) Date: Mon, 2 Jul 2012 15:57:31 -0400 From: Jeffrey Haas To: Yael Frank Dayan Subject: Re: BFD on LAGs - 04 published Message-ID: <20120702195731.GZ18361@pfrc> References: <20120606174012.GA13679@pfrc> <70A1AFC4870DD34181EF6783D7DAF691056BCA09@CMP-EX-DB2.cmpsys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70A1AFC4870DD34181EF6783D7DAF691056BCA09@CMP-EX-DB2.cmpsys.com> 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: Mon, 02 Jul 2012 19:57:27 -0000 Yael, On Mon, Jun 25, 2012 at 01:31:24PM +0000, Yael Frank Dayan wrote: > 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? As Manav has separately answered, that is our intention. However, as discussion among the authors has shown we still have a little way to go to define what the remote IP address will be in various scenarios. One example scenario is unnumbered IP interfaces. A second example is when a link is provisioned with 802.1q - which VLANs address do we use, if any? The authors are adding some text in the upcoming -05 to attempt to discuss this case. > Yael -- Jeff From jhaas@slice.pfrc.org Mon Jul 2 13:33:13 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 A701311E80F4 for ; Mon, 2 Jul 2012 13:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Wagx3Eey9ep4 for ; Mon, 2 Jul 2012 13:33:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3911B11E80E7 for ; Mon, 2 Jul 2012 13:33:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 527D6D1FB; Mon, 2 Jul 2012 16:33:17 -0400 (EDT) Date: Mon, 2 Jul 2012 16:33:17 -0400 From: Jeffrey Haas To: Greg Mirsky Subject: Re: BFD on LAGs - 04 published Message-ID: <20120702203317.GE18361@pfrc> References: <20120606174012.GA13679@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: Mon, 02 Jul 2012 20:33:13 -0000 Greg, On Thu, Jun 21, 2012 at 05:05:25PM -0700, Greg Mirsky wrote: > 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. Thanks for your comment. RFC 6428 does provide some clear examples about how the mechanism there can provide mis-connectivity diagnostics. In the current version of the draft, -04, LACP is used to provide the mis-connectivity verification. The draft, however, also provides for the ability to use the feature in the absence of LACP and it's worth considering how connectivity errors can be diagnosed in that mode. At this time I'd suggest that the text remain as it is. We can continue to explore connectivity verification in the absence of LACP in future versions of the draft with input from the working group. -- Jeff From internet-drafts@ietf.org Mon Jul 2 21:14:38 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 24FA311E8139; Mon, 2 Jul 2012 21:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 zF-kR5SVfsLJ; Mon, 2 Jul 2012 21:14:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE1A11E811D; Mon, 2 Jul 2012 21:14:37 -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-hmac-sha-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120703041437.5817.48219.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 21:14:37 -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: Tue, 03 Jul 2012 04:14:38 -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 : Authenticating BFD using HMAC-SHA-2 procedures Author(s) : Dacheng Zhang Manav Bhatia Vishwas Manral Filename : draft-ietf-bfd-hmac-sha-01.txt Pages : 10 Date : 2012-07-02 Abstract: This document describes the mechanism to authenticate Bidirectional Forwarding Detection (BFD) protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms. The mechanism described uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This document updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-hmac-sha There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-hmac-sha-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-hmac-sha-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From manav.bhatia@alcatel-lucent.com Fri Jul 6 16:42:05 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 C90A911E80BC for ; Fri, 6 Jul 2012 16:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OwPqD+pZbsjr for ; Fri, 6 Jul 2012 16:42:05 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3869D11E8093 for ; Fri, 6 Jul 2012 16:42:05 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q66NfvxM018607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Jul 2012 18:42:21 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q66Nfv73023658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 7 Jul 2012 05:11:57 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sat, 7 Jul 2012 05:11:57 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Sat, 7 Jul 2012 05:11:58 +0530 Subject: BFD over LAGs updated Thread-Topic: BFD over LAGs updated Thread-Index: Ac1b0O7bl8chL4OzSaOXUmUgkh2z6g== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0615B254@INBANSXCHMBSA1.in.alcatel-lucent.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 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, 06 Jul 2012 23:42:05 -0000 Hi, We have posted an updated version of BFD over LAGs. http://www.ietf.org/id/draft-mmm-bfd-on-lags-05.txt Diff from the last version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-05 Would appreciate if the WG members can review this version and provide feed= back. Cheers, Manav= From toms.sanders@gmail.com Mon Jul 9 08:22:38 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 107E511E808C for ; Mon, 9 Jul 2012 08:22:38 -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 FgyY-677Uwey for ; Mon, 9 Jul 2012 08:22:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F14311E8080 for ; Mon, 9 Jul 2012 08:22:36 -0700 (PDT) Received: by were53 with SMTP id e53so2245407wer.31 for ; Mon, 09 Jul 2012 08:23:01 -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=B0wQQThcRSxdo7n6++8gcNKYZwHiUNouWdOuqgmAEXE=; b=wVoiRT65lz1Bh/s2xJK3HswgLLFr9KmhTKk92vXRQ0BgXx2/nnZ08rcck+cPrhwZ4A hePOM+YJToS25cEwQ40INF4wo1EDLMjd6iLNDApUNntzy42qnlNPh+ZXAxjIt2iwwwaL 4FSQYfKJbulbp1/Nrfg/Zd0LrOn/wXjhd3GWUDPdISFxFHVodXLwVsw5nYv9X0FeQE/3 1Md7X6tG1WNx4zySq5l4fsVJdQwFUoprnnW6jrTShyAKvs9qR+4Lflt5d+hvkYURHE1V uuvsajjKMctYsOiJ0F5Z2tES38tgr0Is0YLpokwoCM9df/+63jjGAiRiBYKnimwfz8b9 e5Zw== MIME-Version: 1.0 Received: by 10.180.106.137 with SMTP id gu9mr30314791wib.20.1341847381625; Mon, 09 Jul 2012 08:23:01 -0700 (PDT) Received: by 10.223.72.6 with HTTP; Mon, 9 Jul 2012 08:23:01 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0615B254@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D0615B254@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 9 Jul 2012 20:53:01 +0530 Message-ID: Subject: Re: BFD over LAGs updated From: Tom Sanders To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=UTF-8 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: Mon, 09 Jul 2012 15:22:38 -0000 Hi Manav, I understand that micro BFD session packets go with unicast ip addresses. The question is that how will i figure out the IP to fill in the micro BFD packets? Toms On 7 July 2012 05:11, Bhatia, Manav (Manav) wrote: > Hi, > > We have posted an updated version of BFD over LAGs. > > http://www.ietf.org/id/draft-mmm-bfd-on-lags-05.txt > > Diff from the last version: > http://tools.ietf.org/rfcdiff?url2=draft-mmm-bfd-on-lags-05 > > Would appreciate if the WG members can review this version and provide feedback. > > Cheers, Manav -- Toms. From jhaas@slice.pfrc.org Mon Jul 9 08:47: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 0B41A11E80F8 for ; Mon, 9 Jul 2012 08:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.283 X-Spam-Level: X-Spam-Status: No, score=-101.283 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_20=-0.74, 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 qYQoq4gmo6PJ for ; Mon, 9 Jul 2012 08:47:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 00C7911E80F7 for ; Mon, 9 Jul 2012 08:47:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id BFB64C69C; Mon, 9 Jul 2012 11:47:31 -0400 (EDT) Date: Mon, 9 Jul 2012 11:47:31 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 84 meeting - call for presentations Message-ID: <20120709154731.GB22984@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: Mon, 09 Jul 2012 15:47:08 -0000 Working Group, We shall be meeting at the upcoming IETF 84 session in Vancouver, Canada. This is a call for presentations for the working group session. Since the majority of the working group focus has been over the BFD over Ethernet LAG feature, we will be reserving a 30 minute time slot for update and discussion on this feature. Note that this draft is still an individual submission as we are gated on a response from IEEE regarding this work. At the moment, that token is waiting on AD review of the chairs proposed response to IEEE. (Ahem!) Similar to prior WG sessions, we would request that presentations be completed several days prior so they can be uploaded to the datatracker. This will let the session be most efficiently used for discussion rather than reading the slides aloud. For documents that are refreshes with minor changes and don't require a full presentation, authors are encouraged to provide a slide for the meeting materials but need not present unless there is desire for discussion. Finally, I'd like to encourage the WG to spend a little focus on the BFD MIB documents. The base MIB has been re-published and needs some audit work against the new WG item for the MIB for BFD for MPLS(-TP). As noted in prior e-mail threads, the WG doesn't have a requirement from ITU-T to provide read-write access to such a MIB, but there has been support of a writeable MIB from within the WG. This means that read-create objects in the MPLS MIB must have appropriate read-create coverage of supporting rows in the base MIB. -- Jeff and Dave. From gregory.mirsky@ericsson.com Mon Jul 9 16:31:50 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 403FE11E8150 for ; Mon, 9 Jul 2012 16:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 75nPGgWY6mxn for ; Mon, 9 Jul 2012 16:31:48 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 719A211E813F for ; Mon, 9 Jul 2012 16:31:48 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q69NW84w016176; Mon, 9 Jul 2012 18:32:10 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 9 Jul 2012 19:32:03 -0400 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , "mach.chen@huawei.com" , "sboutros@cisco.com" , "mbinderb@cisco.com" , "jhaas@juniper.net" , "rtg-bfd@ietf.org" Date: Mon, 9 Jul 2012 19:32:01 -0400 Subject: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Topic: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Index: Ac1eKwodE4Oc6ROVSUCsxLIwPUEERQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D719204FEUSAACMS0715e_" 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, 09 Jul 2012 23:31:50 -0000 --_000_FE60A4E52763E84B935532D7D9294FF137D719204FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Editors, Authors, et al. Please find couple of questions from me to the lastest version of micro-BFD= draft: * Introduction "... (3) and would be able to verify L3 connectivity p= er member link." Since BFD is encapsulation independent to monitor path continuity, ability = to verify L3 continuity is result of using IP encapsulation. It is possible= to use GAL/G-ACh encapsulation, per RFC 5586, Section 4, with GAL being th= e only MPLS label in the label stack. But introduction of MPLS layer in mon= itoring LAG's member links might as well introduce defects that are not rel= ated to Ethernet layer. That same, IMO, is true for L3. * Introduction. "The goal is to verify link connectivity for every me= mber link." If the goal is to monitor connectivity, then we need to define mis-connecti= vity defects, entry and exit criterias accordingly. * Section 2.3 There seems to be a contradiction in the last para rega= rding tagging micro BFD control packets. Consider the very first sentence "= Micro BFD packets MUST always be sent untagged." And further down "It is RE= COMMENDED that micro BFD packets should always be sent untagged." So, is it= thou SHOULD tag micro BFD packets? * Section 3.1 I think that characterization of BFD in the second para "BFD, as a layer 3 = protocol" is not correct. BFD is encapsulation and hence layer independent = protocol to monitor path continuity (bi-directional as of now and uni-direc= tional very soon) at layer defined by type of encapsulation used. * And one more question. Consider that a micro BFD session went down = on one of member links. If LACP is present, then, according to Section 3.1,= micro BFD on that link should be put in Passive mode until LACP determines= that "a link is suitable for aggregation within its selected LAG and has c= ompleted negotiations with the partner device so as to bring that link to D= istributing state ...". Is that correct understanding? Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF137D719204FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Editors, Authors, et al.
Please find couple of questions from me to the lastest version of micr= o-BFD draft:
  • Introduction "… (3) and would be able to verify L3 connectiv= ity per member link."
Since BFD is encapsulation independent = to monitor path continuity, ability to verify L3 continuity is result of us= ing IP encapsulation. It is possible to use GAL/G-ACh encapsulation, per RF= C 5586, Section 4, with GAL being the only MPLS label in the label stack. But introduction of MPLS layer in m= onitoring LAG's member links might as well introduce defects that are not r= elated to Ethernet layer. That same, IMO, is true for L3.
  • Introduction. "The goal is to verify link connectivity for every m= ember link."
If the goal is to monitor connectivity,= then we need to define mis-connectivity defects, entry and exit criterias = accordingly.
  • Section 2.3 There seems to be a contradiction in the last para regardin= g tagging micro BFD control packets. Consider the very first sentence "= ;Micro BFD packets MUST always be sent untagged." And further down &qu= ot;It is RECOMMENDED that micro BFD packets should always be sent untagged." So, is it thou SHOULD tag micro BFD packets?=
  • Section 3.1
I think that characterization of BFD in= the second para "BFD, as a layer 3 protocol" is not correct. BFD= is encapsulation and hence layer independent protocol to monitor path cont= inuity (bi-directional as of now and uni-directional very soon) at layer defined by type of encapsulation used.
  • And one more question. Consider that a micro BFD session went down on o= ne of member links. If LACP is present, then, according to Section 3.1, mic= ro BFD on that link should be put in Passive mode until LACP determines tha= t "a link is suitable for aggregation within its selected LAG and has completed negotiations with the partner dev= ice so as to bring that link to Distributing state …". Is that c= orrect understanding?
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF137D719204FEUSAACMS0715e_-- From manav.bhatia@alcatel-lucent.com Mon Jul 9 21:45: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 77E1911E8116 for ; Mon, 9 Jul 2012 21:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 jikYwWVoUVFD for ; Mon, 9 Jul 2012 21:45:06 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E411E810C for ; Mon, 9 Jul 2012 21:45:05 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q6A4jRWQ025179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jul 2012 23:45:29 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6A4jQhF013269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Jul 2012 10:15:26 +0530 Received: from [135.250.26.223] (135.250.19.8) by INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 10 Jul 2012 10:15:23 +0530 Message-ID: <4FFBB2A4.2040803@alcatel-lucent.com> Date: Tue, 10 Jul 2012 10:12:12 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Gregory Mirsky Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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, 10 Jul 2012 04:45:08 -0000 Hi Greg, On 7/10/2012 5:02 AM, Gregory Mirsky wrote: > Dear Editors, Authors, et al. > Please find couple of questions from me to the lastest version of > micro-BFD draft: > > * Introduction "… (3) and would be able to verify L3 connectivity per > member link." > > Since BFD is encapsulation independent to monitor path continuity, > ability to verify L3 continuity is result of using IP encapsulation. It > is possible to use GAL/G-ACh encapsulation, per RFC 5586, Section 4, > with GAL being the only MPLS label in the label stack. But introduction > of MPLS layer in monitoring LAG's member links might as well introduce > defects that are not related to Ethernet layer. That same, IMO, is true > for L3. I am afraid i dont understand the comment. Are you suggesting that using L3 encapsulation can not catch errors in ethernet layer? > > * Introduction. "The goal is to verify link connectivity for every > member link." > > If the goal is to monitor connectivity, then we need to define > mis-connectivity defects, entry and exit criterias accordingly. Again, i dont understand this. What do you mean by entry and exit criterias? > > * Section 2.3 There seems to be a contradiction in the last para > regarding tagging micro BFD control packets. Consider the very first > sentence "Micro BFD packets MUST always be sent untagged." And > further down "It is RECOMMENDED that micro BFD packets should always > be sent untagged." So, is it thou SHOULD tag micro BFD packets? Will replace the text to say that Micro BFD packets SHOULD always be sent untagged. > * Section 3.1 > > I think that characterization of BFD in the second para "BFD, as a layer > 3 protocol" is not correct. BFD is encapsulation and hence layer > independent protocol to monitor path continuity (bi-directional as of > now and uni-directional very soon) at layer defined by type of > encapsulation used. Do you have any replacement text in mind? > > * And one more question. Consider that a micro BFD session went down > on one of member links. If LACP is present, then, according to > Section 3.1, micro BFD on that link should be put in Passive mode > until LACP determines that "a link is suitable for aggregation > within its selected LAG and has completed negotiations with the > partner device so as to bring that link to Distributing state …". Is > that correct understanding? Yes. The idea is that the micro BFD sessions will not influence LACP. We will let LACP follow its usual state machine. The link will only be used for L3 forwarding once the micro BFD sessions are UP. In the presence of LACP, the micro sessions only become active once LACP enters the Distributing state. Cheers, Manav From manav.bhatia@alcatel-lucent.com Mon Jul 9 21:47:49 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 3A4AB21F84F3 for ; Mon, 9 Jul 2012 21:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 DOqgHW891GpE for ; Mon, 9 Jul 2012 21:47:48 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F621F8441 for ; Mon, 9 Jul 2012 21:47:47 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q6A4m8Sf004906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jul 2012 23:48:11 -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 q6A4m8dO002378 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Jul 2012 10:18:08 +0530 Received: from [135.250.26.223] (135.250.19.8) by INBANSXCHHUB01.in.alcatel-lucent.com (135.250.12.32) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 10 Jul 2012 10:18:07 +0530 Message-ID: <4FFBB348.6030608@alcatel-lucent.com> Date: Tue, 10 Jul 2012 10:14:56 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tom Sanders Subject: Re: BFD over LAGs updated References: <7C362EEF9C7896468B36C9B79200D8350D0615B254@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 10 Jul 2012 04:47:49 -0000 Hi Toms, The IP address of the remote end needs to be explicitly configured. If you dont want to manually configure the IP addresses then you can look at draft-mmsn-bfd-on-lags-address-00.txt to see how this IP address can be dynamically discovered. Cheers, Manav On 7/9/2012 8:53 PM, Tom Sanders wrote: > Hi Manav, > > I understand that micro BFD session packets go with unicast ip > addresses. The question is that how will i figure out the IP to fill > in the micro BFD packets? > > Toms > > On 7 July 2012 05:11, Bhatia, Manav (Manav) > wrote: >> Hi, >> >> We have posted an updated version of BFD over LAGs. >> >> http://www.ietf.org/id/draft-mmm-bfd-on-lags-05.txt >> >> Diff from the last version: >> http://tools.ietf.org/rfcdiff?url2=draft-mmm-bfd-on-lags-05 >> >> Would appreciate if the WG members can review this version and provide feedback. >> >> Cheers, Manav > > > From gregory.mirsky@ericsson.com Tue Jul 10 13:27:02 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 034AC21F86AA for ; Tue, 10 Jul 2012 13:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 N7E8jeWo6WxW for ; Tue, 10 Jul 2012 13:26:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 20DB111E80D0 for ; Tue, 10 Jul 2012 13:26:59 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6AKRACv013495; Tue, 10 Jul 2012 15:27:25 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 10 Jul 2012 16:27:17 -0400 From: Gregory Mirsky To: Manav Bhatia Date: Tue, 10 Jul 2012 16:27:16 -0400 Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Topic: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Index: Ac1eVtexdmHARM2SS4W9e56NExIjXwAf3wGA Message-ID: References: <4FFBB2A4.2040803@alcatel-lucent.com> In-Reply-To: <4FFBB2A4.2040803@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D71924CEEUSAACMS0715e_" 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: Tue, 10 Jul 2012 20:27:02 -0000 --_000_FE60A4E52763E84B935532D7D9294FF137D71924CEEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, Thank you for expedient response to my questions. Please find my comments = in-lined and tagged by GIM>>. Regards, Greg -----Original Message----- From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] Sent: Monday, July 09, 2012 9:42 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt Hi Greg, On 7/10/2012 5:02 AM, Gregory Mirsky wrote: > Dear Editors, Authors, et al. > Please find couple of questions from me to the lastest version of > micro-BFD draft: > > * Introduction "... (3) and would be able to verify L3 connectivity per > member link." > > Since BFD is encapsulation independent to monitor path continuity, > ability to verify L3 continuity is result of using IP encapsulation. > It is possible to use GAL/G-ACh encapsulation, per RFC 5586, Section > 4, with GAL being the only MPLS label in the label stack. But > introduction of MPLS layer in monitoring LAG's member links might as > well introduce defects that are not related to Ethernet layer. That > same, IMO, is true for L3. I am afraid i dont understand the comment. Are you suggesting that using L3 encapsulation can not catch errors in ethernet layer? GIM>> I don't see point 3, use of IP encapsulation, as benefit but rather a= s potential source of defects not related to LAG itself. > > * Introduction. "The goal is to verify link connectivity for every > member link." > > If the goal is to monitor connectivity, then we need to define > mis-connectivity defects, entry and exit criterias accordingly. Again, i dont understand this. What do you mean by entry and exit criterias= ? GIM>> Defect's entry criteria defines what actually constitutes beginning o= f the state of defect. Defect's exit criteria defines what constitues clear= ing of particular defect. For example, entry criteria for Loss of Continuit= y is expiration of a timer associated with far end; exit criteria for Loss = of Continuity defect, e.g. as defined in RFC 6428, "occurs upon receipt of = a well-formed BFD control packet from the peer MEP". > > * Section 2.3 There seems to be a contradiction in the last para > regarding tagging micro BFD control packets. Consider the very first > sentence "Micro BFD packets MUST always be sent untagged." And > further down "It is RECOMMENDED that micro BFD packets should always > be sent untagged." So, is it thou SHOULD tag micro BFD packets? Will replace the text to say that Micro BFD packets SHOULD always be sent u= ntagged. > * Section 3.1 > > I think that characterization of BFD in the second para "BFD, as a > layer > 3 protocol" is not correct. BFD is encapsulation and hence layer > independent protocol to monitor path continuity (bi-directional as of > now and uni-directional very soon) at layer defined by type of > encapsulation used. Do you have any replacement text in mind? GIM>> Perhaps the following: "BFD, as media independent protocol, ..." or "= BFD with IP encapsulation, as layer 3 protocol, ..." > > * And one more question. Consider that a micro BFD session went down > on one of member links. If LACP is present, then, according to > Section 3.1, micro BFD on that link should be put in Passive mode > until LACP determines that "a link is suitable for aggregation > within its selected LAG and has completed negotiations with the > partner device so as to bring that link to Distributing state ...". I= s > that correct understanding? Yes. The idea is that the micro BFD sessions will not influence LACP. We will le= t LACP follow its usual state machine. The link will only be used for L3 forwarding once the micro BFD sessions are UP. In the presence of LACP, = the micro sessions only become active once LACP enters the Distributing sta= te. Cheers, Manav --_000_FE60A4E52763E84B935532D7D9294FF137D71924CEEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Manav,
Thank you for  expedient response to my questions. Please find my= comments in-lined and tagged by GIM>>.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
Sent: Monday, July 09, 2012 9:42 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org
Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt
 
Hi Greg,
 
On 7/10/2012 5:02 AM, Gregory Mirsky wrote:
> Dear Editors, Authors, et al.
> Please find couple of questions from me to the lastest version of=
> micro-BFD draft:
>
>   * Introduction "… (3) and would be able to= verify L3 connectivity per
>     member link."
>
> Since BFD is encapsulation independent to monitor path continuity= ,
> ability to verify L3 continuity is result of using IP encapsulati= on.
> It is possible to use GAL/G-ACh encapsulation, per RFC 5586, Sect= ion
> 4, with GAL being the only MPLS label in the label stack. But
> introduction of MPLS layer in monitoring LAG's member links might= as
> well introduce defects that are not related to Ethernet layer. Th= at
> same, IMO, is true for L3.
 
I am afraid i dont understand the comment. Are you suggesting that usi= ng
L3 encapsulation can not catch errors in ethernet layer?
 
GIM>> I don't see point 3, use of IP enc= apsulation, as benefit but rather as potential source of defects not relate= d to LAG itself.
 
>
>   * Introduction. "The goal is to verify link conn= ectivity for every
>     member link."
>
> If the goal is to monitor connectivity, then we need to define
> mis-connectivity defects, entry and exit criterias accordingly.
 
Again, i dont understand this. What do you mean by entry and exit crit= erias?
 
GIM>> Defect's entry criteria defines wh= at actually constitutes beginning of the state of defect. Defect's exit cri= teria defines what constitues clearing of particular defect. For example, e= ntry criteria for Loss of Continuity is expiration of a timer associated with far end; exit criteria for Loss of Co= ntinuity defect, e.g. as defined in RFC 6428, "occurs upon receipt of = a well-formed BFD control packet from the peer MEP".
 
>
>   * Section 2.3 There seems to be a contradiction in th= e last para
>     regarding tagging micro BFD control packe= ts. Consider the very first
>     sentence "Micro BFD packets MUST alw= ays be sent untagged." And
>     further down "It is RECOMMENDED that= micro BFD packets should always
>     be sent untagged." So, is it thou SH= OULD tag micro BFD packets?
 
Will replace the text to say that Micro BFD packets SHOULD always be s= ent untagged.
 
>   * Section 3.1
>
> I think that characterization of BFD in the second para "BFD= , as a
> layer
> 3 protocol" is not correct. BFD is encapsulation and hence l= ayer
> independent protocol to monitor path continuity (bi-directional a= s of
> now and uni-directional very soon) at layer defined by type of
> encapsulation used.
 
Do you have any replacement text in mind?
 
GIM>> Perhaps the following: "BFD, = as media independent protocol, …" or "BFD with IP encapsula= tion, as layer 3 protocol, …"
 
>
>   * And one more question. Consider that a micro BFD se= ssion went down
>     on one of member links. If LACP is presen= t, then, according to
>     Section 3.1, micro BFD on that link shoul= d be put in Passive mode
>     until LACP determines that "a link i= s suitable for aggregation
>     within its selected LAG and has completed= negotiations with the
>     partner device so as to bring that link t= o Distributing state …". Is
>     that correct understanding?
 
Yes.
 
The idea is that the micro BFD sessions will not influence LACP. We wi= ll let LACP follow its usual state machine. The link will only be used for<= /div>
L3 forwarding once the micro BFD sessions are UP. In the presence of L= ACP, the micro sessions only become active once LACP enters the Distributin= g state.
 
Cheers, Manav
 
 --_000_FE60A4E52763E84B935532D7D9294FF137D71924CEEUSAACMS0715e_-- From manav.bhatia@alcatel-lucent.com Tue Jul 10 15:57:11 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 62E6111E80BE for ; Tue, 10 Jul 2012 15:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Qr7a8Pu7sIaS for ; Tue, 10 Jul 2012 15:57:10 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C763511E809F for ; Tue, 10 Jul 2012 15:57:10 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q6AMvXiP005790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jul 2012 17:57:36 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6AMvX9d003610 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Jul 2012 04:27:33 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 11 Jul 2012 04:27:32 +0530 From: "Bhatia, Manav (Manav)" To: Gregory Mirsky Date: Wed, 11 Jul 2012 04:27:45 +0530 Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Topic: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Index: Ac1eVtexdmHARM2SS4W9e56NExIjXwAf3wGAAAYMzlA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4FFBB2A4.2040803@alcatel-lucent.com> 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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, 10 Jul 2012 22:57:11 -0000 Hi Greg, [clipped] =20 > I am afraid i dont understand the comment. Are you suggesting that using > L3 encapsulation can not catch errors in ethernet layer? =20 GIM>> I don't see point 3, use of IP encapsulation, as benefit but rather a= s potential source of defects not related to LAG itself. Are you suggesting that we DON'T use IP encapsulation for micro BFD packets= ? I believe we had discussed the pros and cons of using IP encap vis-a-vis = other encaps in the WG and this was the consensus that everyone had eventua= lly arrived at. [clipped] =20 > > * Introduction. "The goal is to verify link connectivity for every > member link." > > If the goal is to monitor connectivity, then we need to define=20 > mis-connectivity defects, entry and exit criterias accordingly. =20 > Again, i dont understand this. What do you mean by entry and exit criteri= as? =20 GIM>> Defect's entry criteria defines what actually constitutes beginning o= f the state of defect. Defect's exit criteria defines what constitues clear= ing of particular defect. For example, entry criteria for Loss of Continuit= y is expiration of a timer associated with far end; exit criteria for Loss = of Continuity defect, e.g. as defined in RFC 6428, "occurs upon receipt of = a well-formed BFD control packet from the peer MEP". I would wager that the entry and exit criteron for micro BFD would be the s= ame as the regular rfc 5881 BFD. Why would this be any different? [clipped] =20 > Do you have any replacement text in mind? =20 GIM>> Perhaps the following: "BFD, as media independent protocol, ..." or "= BFD with IP encapsulation, as layer 3 protocol, ..." Sure, I have no issues with this text. Will update it as long as my co-auth= ors don't raise any objections with this. Cheers, Manav= From gregory.mirsky@ericsson.com Tue Jul 10 22:50: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 ECA1611E80BA for ; Tue, 10 Jul 2012 22:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 DccI5vNpa2-V for ; Tue, 10 Jul 2012 22:50:58 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 04B0311E8073 for ; Tue, 10 Jul 2012 22:50:57 -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 q6B5pPs3022537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 00:51:26 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 11 Jul 2012 01:51:25 -0400 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" Date: Wed, 11 Jul 2012 01:51:23 -0400 Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Topic: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Index: Ac1eVtexdmHARM2SS4W9e56NExIjXwAf3wGAAAYMzlAADi2kAA== Message-ID: References: <4FFBB2A4.2040803@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D7192650EUSAACMS0715e_" 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, 11 Jul 2012 05:50:59 -0000 --_000_FE60A4E52763E84B935532D7D9294FF137D7192650EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, Just couple more comments in-lined and tagged by GIM>>>> this time. Regards, Greg -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] Sent: Tuesday, July 10, 2012 3:58 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Hi Greg, [clipped] > I am afraid i dont understand the comment. Are you suggesting that > using > L3 encapsulation can not catch errors in ethernet layer? GIM>> I don't see point 3, use of IP encapsulation, as benefit but rather a= s potential source of defects not related to LAG itself. Are you suggesting that we DON'T use IP encapsulation for micro BFD packets= ? I believe we had discussed the pros and cons of using IP encap vis-a-vis = other encaps in the WG and this was the consensus that everyone had eventua= lly arrived at. GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD but I'm s= uggesting thoroughly document what could be implications of using IP encaps= ulation of BFD to monitor Layer 2 path. [clipped] > > * Introduction. "The goal is to verify link connectivity for every > member link." > > If the goal is to monitor connectivity, then we need to define > mis-connectivity defects, entry and exit criterias accordingly. > Again, i dont understand this. What do you mean by entry and exit criteri= as? GIM>> Defect's entry criteria defines what actually constitutes beginning o= f the state of defect. Defect's exit criteria defines what constitues clear= ing of particular defect. For example, entry criteria for Loss of Continuit= y is expiration of a timer associated with far end; exit criteria for Loss = of Continuity defect, e.g. as defined in RFC 6428, "occurs upon receipt of = a well-formed BFD control packet from the peer MEP". I would wager that the entry and exit criteron for micro BFD would be the s= ame as the regular rfc 5881 BFD. Why would this be any different? GIM>>>> As I've noted earlier, many BFD related document use term "connecti= vity" when in fact discussing "continuity". But these are not the same, not= identical. If the draft we're discussing uses "connectivity" in place of"c= ontinuity", then a note with explanation should, IMHO, suffice. But if inte= ntion is to go beyond RFC 5880 and monitor connectivity, then mis-connectio= n defects have to be defined. [clipped] > Do you have any replacement text in mind? GIM>> Perhaps the following: "BFD, as media independent protocol, ..." or "= BFD with IP encapsulation, as layer 3 protocol, ..." Sure, I have no issues with this text. Will update it as long as my co-auth= ors don't raise any objections with this. Cheers, Manav --_000_FE60A4E52763E84B935532D7D9294FF137D7192650EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Manav,
Just couple more comments in-lined and tagged by GIM>>>> t= his time.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Bhatia, Manav (Manav) [mail= to:manav.bhatia@alcatel-lucent.com]
Sent: Tuesday, July 10, 2012 3:58 PM<= /font>
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org
Subject: RE: Comments on draft-mmm-bf= d-on-lags-05.txt
 
Hi Greg,
 
[clipped]
 
> I am afraid i dont understand th= e comment. Are you suggesting that
> using
> L3 encapsulation can not catch e= rrors in ethernet layer?
      &= nbsp;
GIM>> I don't see point 3, use = of IP encapsulation, as benefit but rather as potential source of defects n= ot related to LAG itself.
 
Are you suggesting that we DON'T use = IP encapsulation for micro BFD packets? I believe we had discussed the pros= and cons of using IP encap vis-a-vis other encaps in the WG and this was t= he consensus that everyone had eventually arrived at.
 
GIM>>>> No, I'm not suggesting not= to use IP encapsulation of BFD but I'm suggesting thoroughly document what= could be implications of using IP encapsulation of BFD to monitor Layer 2 = path.
 
[clipped]
      &= nbsp;
>
>   * Introduction. &quo= t;The goal is to verify link connectivity for every
>     member l= ink."
>
> If the goal is to monitor connec= tivity, then we need to define
> mis-connectivity defects, entry = and exit criterias accordingly.
      &= nbsp;
> Again, i dont understand this. W= hat do you mean by entry and exit criterias?
      &= nbsp;
GIM>> Defect's entry criteria d= efines what actually constitutes beginning of the state of defect. Defect's= exit criteria defines what constitues clearing of particular defect. For e= xample, entry criteria for Loss of Continuity is expiration of a timer associated with far end; exit criteria for Loss of= Continuity defect, e.g. as defined in RFC 6428, "occurs upon receipt = of a well-formed BFD control packet from the peer MEP".
 
I would wager that the entry and exit= criteron for micro BFD would be the same as the regular rfc 5881 BFD. Why = would this be any different?
 
GIM>>>> As I've noted earlier, man= y BFD related document use term "connectivity" when in fact discu= ssing "continuity". But these are not the same, not identical. If= the draft we're discussing uses "connectivity" in place of"= continuity", then a note with explanation should, IMHO, suffice. But if intention is to = go beyond RFC 5880 and monitor connectivity, then mis-connection defects ha= ve to be defined.
 
[clipped]
      &= nbsp;
> Do you have any replacement text= in mind?
      &= nbsp;
GIM>> Perhaps the following: &q= uot;BFD, as media independent protocol, ..." or "BFD with IP enca= psulation, as layer 3 protocol, ..."
 
Sure, I have no issues with this text= . Will update it as long as my co-authors don't raise any objections with t= his.
 
Cheers, Manav
 
 --_000_FE60A4E52763E84B935532D7D9294FF137D7192650EUSAACMS0715e_-- From manav.bhatia@alcatel-lucent.com Tue Jul 10 23:46: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 B8C0E11E80E8 for ; Tue, 10 Jul 2012 23:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.799 X-Spam-Level: X-Spam-Status: No, score=-7.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 tGcZ5+K1-4dW for ; Tue, 10 Jul 2012 23:46:09 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C041B11E80D1 for ; Tue, 10 Jul 2012 23:46:09 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q6B6kVXD028521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jul 2012 01:46:33 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6B6kUns022314 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Jul 2012 12:16:31 +0530 Received: from [135.250.26.223] (135.250.19.8) by INBANSXCHHUB02.in.alcatel-lucent.com (135.250.12.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jul 2012 12:16:30 +0530 Message-ID: <4FFD2086.9070404@alcatel-lucent.com> Date: Wed, 11 Jul 2012 12:13:18 +0530 From: Manav Bhatia User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Gregory Mirsky Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt References: <4FFBB2A4.2040803@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 11 Jul 2012 06:46:10 -0000 Hi Gregory, > GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD but > I'm suggesting thoroughly document what could be implications of using > IP encapsulation of BFD to monitor Layer 2 path. Sure this should be done. We can take it up as an additional draft so that we dont stall the progress of this one. This is precisely why we kept the mechanism to dynamically learn the remote IP addresses in a separate draft (draft-mmsn-bfd-on-lags-address-00.txt). We can also later explore the possibility of merging these drafts into the main draft, if thats the WG consensus then. > I would wager that the entry and exit criteron for micro BFD would be > the same as the regular rfc 5881 BFD. Why would this be any different? > > GIM>>>> As I've noted earlier, many BFD related document use term > "connectivity" when in fact discussing "continuity". But these are not > the same, not identical. If the draft we're discussing uses > "connectivity" in place of"continuity", then a note with explanation > should, IMHO, suffice. But if intention is to go beyond RFC 5880 and > monitor connectivity, then mis-connection defects have to be defined. Would s/connectivity/continuity help? :-) Cheers, Manav From gregory.mirsky@ericsson.com Wed Jul 11 11:08: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 8EB2C11E80DB for ; Wed, 11 Jul 2012 11:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 R7wozyb53bGh for ; Wed, 11 Jul 2012 11:08:11 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D192F11E80CD for ; Wed, 11 Jul 2012 11:08:11 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6BI8bSf015715; Wed, 11 Jul 2012 13:08:41 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 11 Jul 2012 14:08:37 -0400 From: Gregory Mirsky To: Manav Bhatia Date: Wed, 11 Jul 2012 14:08:36 -0400 Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Topic: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Index: Ac1fMOzp8nvCtmtFRkCdPkODk1vzKAAXaynw Message-ID: References: <4FFBB2A4.2040803@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> <4FFD2086.9070404@alcatel-lucent.com> In-Reply-To: <4FFD2086.9070404@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D71928E9EUSAACMS0715e_" 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, 11 Jul 2012 18:08:12 -0000 --_000_FE60A4E52763E84B935532D7D9294FF137D71928E9EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, Glad we're converging. Certainly the editorial changes you've proposing will address my concern. But I frankly don't see need for a separate document just to express my con= cern regarding use of IP encapsulation. Simple sentense like "Use of IP enc= apsulation may introduce Layer 3 defects that be positive negatives to moni= tored LAG." would be sufficient IMHO. Regards, Greg -----Original Message----- From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] Sent: Tuesday, July 10, 2012 11:43 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt Hi Gregory, > GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD but > I'm suggesting thoroughly document what could be implications of using > IP encapsulation of BFD to monitor Layer 2 path. Sure this should be done. We can take it up as an additional draft so that = we dont stall the progress of this one. This is precisely why we kept the m= echanism to dynamically learn the remote IP addresses in a separate draft (= draft-mmsn-bfd-on-lags-address-00.txt). We can also later explore the possibility of merging these drafts into the = main draft, if thats the WG consensus then. > I would wager that the entry and exit criteron for micro BFD would be > the same as the regular rfc 5881 BFD. Why would this be any different? > > GIM>>>> As I've noted earlier, many BFD related document use term > "connectivity" when in fact discussing "continuity". But these are not > the same, not identical. If the draft we're discussing uses > "connectivity" in place of"continuity", then a note with explanation > should, IMHO, suffice. But if intention is to go beyond RFC 5880 and > monitor connectivity, then mis-connection defects have to be defined. Would s/connectivity/continuity help? :-) Cheers, Manav --_000_FE60A4E52763E84B935532D7D9294FF137D71928E9EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Manav,
Glad we're converging.
Certainly the editorial changes you've proposing will address my conce= rn.
But I frankly don't see need for a separate document just to express m= y concern regarding use of IP encapsulation. Simple sentense like "Use= of IP encapsulation may introduce Layer 3 defects that be positive negativ= es to monitored LAG." would be sufficient IMHO.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
Sent: Tuesday, July 10, 2012 11:43 PM=
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org
Subject: Re: Comments on draft-mmm-bf= d-on-lags-05.txt
 
Hi Gregory,
 
> GIM>>>> No, I'm not = suggesting not to use IP encapsulation of BFD but
> I'm suggesting thoroughly docume= nt what could be implications of using
> IP encapsulation of BFD to monit= or Layer 2 path.
 
Sure this should be done. We can take= it up as an additional draft so that we dont stall the progress of this on= e. This is precisely why we kept the mechanism to dynamically learn the rem= ote IP addresses in a separate draft (draft-mmsn-bfd-on-lags-address-00.txt).
 
We can also later explore the possibi= lity of merging these drafts into the main draft, if thats the WG consensus= then.
 
> I would wager that the entry and= exit criteron for micro BFD would be
> the same as the regular rfc 5881= BFD. Why would this be any different?
>
> GIM>>>> As I've note= d earlier, many BFD related document use term
> "connectivity" when in= fact discussing "continuity". But these are not
> the same, not identical. If the = draft we're discussing uses
> "connectivity" in plac= e of"continuity", then a note with explanation
> should, IMHO, suffice. But if in= tention is to go beyond RFC 5880 and
> monitor connectivity, then mis-c= onnection defects have to be defined.
 
Would s/connectivity/continuity help?= :-)
 
Cheers, Manav
 
 --_000_FE60A4E52763E84B935532D7D9294FF137D71928E9EUSAACMS0715e_-- From manav.bhatia@alcatel-lucent.com Thu Jul 12 03:05:55 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 1DCB121F87CB for ; Thu, 12 Jul 2012 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 z+SPbeilXoXT for ; Thu, 12 Jul 2012 03:05:54 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1F01621F8796 for ; Thu, 12 Jul 2012 03:05:53 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q6CA6Lgv014493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jul 2012 05:06:24 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6CA6KDb003966 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Jul 2012 15:36:20 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 12 Jul 2012 15:36:20 +0530 From: "Bhatia, Manav (Manav)" To: Gregory Mirsky Date: Thu, 12 Jul 2012 15:37:10 +0530 Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Topic: Comments on draft-mmm-bfd-on-lags-05.txt Thread-Index: Ac1fMOzp8nvCtmtFRkCdPkODk1vzKAAXaynwACEZVdA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0615BC47@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <4FFBB2A4.2040803@alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D0615B7BA@INBANSXCHMBSA1.in.alcatel-lucent.com> <4FFD2086.9070404@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350D0615BC47INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 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, 12 Jul 2012 10:05:55 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350D0615BC47INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, I hear you when you say that using IP encapsulation for monitoring link sta= tus could give a few false positives/negatives. However, i am wondering if = its a practical concern. Since all micro BFD sessions are single hop, the p= ackets will get dropped if they get rerouted out of some other IP interface= , in effect bringing the micro BFD session down. I, on my part, am unable t= o envisage a scenario when using L3 encap could lead to a false negative/po= sitive. Do you have a scenario or a sequence of events in mind which can de= monstrate the fate of a micro session and the real link status diverging? Isnt the argument akin to saying that ISIS can introduce false positives si= nce its riding on top of Layer 2? Please note that i have no issues in adding the text that you have suggeste= d. I am merely ensuring that we all understand why we're adding the text. Cheers, Manav ________________________________ From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Wednesday, July 11, 2012 11:39 PM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: RE: Comments on draft-mmm-bfd-on-lags-05.txt Hi Manav, Glad we're converging. Certainly the editorial changes you've proposing will address my concern. But I frankly don't see need for a separate document just to express my con= cern regarding use of IP encapsulation. Simple sentense like "Use of IP enc= apsulation may introduce Layer 3 defects that be positive negatives to moni= tored LAG." would be sufficient IMHO. Regards, Greg -----Original Message----- From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com] Sent: Tuesday, July 10, 2012 11:43 PM To: Gregory Mirsky Cc: rtg-bfd@ietf.org Subject: Re: Comments on draft-mmm-bfd-on-lags-05.txt Hi Gregory, > GIM>>>> No, I'm not suggesting not to use IP encapsulation of BFD but > I'm suggesting thoroughly document what could be implications of using > IP encapsulation of BFD to monitor Layer 2 path. Sure this should be done. We can take it up as an additional draft so that = we dont stall the progress of this one. This is precisely why we kept the m= echanism to dynamically learn the remote IP addresses in a separate draft (= draft-mmsn-bfd-on-lags-address-00.txt). We can also later explore the possibility of merging these drafts into the = main draft, if thats the WG consensus then. > I would wager that the entry and exit criteron for micro BFD would be > the same as the regular rfc 5881 BFD. Why would this be any different? > > GIM>>>> As I've noted earlier, many BFD related document use term > "connectivity" when in fact discussing "continuity". But these are not > the same, not identical. If the draft we're discussing uses > "connectivity" in place of"continuity", then a note with explanation > should, IMHO, suffice. But if intention is to go beyond RFC 5880 and > monitor connectivity, then mis-connection defects have to be defined. Would s/connectivity/continuity help? :-) Cheers, Manav --_000_7C362EEF9C7896468B36C9B79200D8350D0615BC47INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Greg,
 
I hear you when you say that using IP encapsu= lation=20 for monitoring link status could give a few false positives/negatives. Howe= ver,=20 i am wondering if its a practical concern. Since all micro BFD sessions are= =20 single hop, the packets will get dropped if they get rerouted out of some o= ther=20 IP interface, in effect bringing the micro BFD session down. I, on my part,= am=20 unable to envisage a scenario when using L3 encap could lead to a false=20 negative/positive. Do you have a scenario or a sequence of events= in=20 mind which can demonstrate the fate of a micro session and the=20 real link status diverging?
 
Isnt the argument akin to saying that ISIS can int= roduce=20 false positives since its riding on top of Layer 2?
 
Please note that i have no issues in adding the te= xt that=20 you have suggested. I am merely ensuring that we all understand why we're a= dding=20 the text.
 <= /DIV>
Chee= rs,=20 Manav
From: Grego= ry Mirsky=20 [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, July 11, 2= 012=20 11:39 PM
To: Bhatia, Manav (Manav)
Cc:=20 rtg-bfd@ietf.org
Subject: RE: Comments on=20 draft-mmm-bfd-on-lags-05.txt

Hi Manav,
Glad we're converging.
Certainly the editorial changes you've proposing will address my=20 concern.
But I frankly don't see need for a separate document just to express= my=20 concern regarding use of IP encapsulation. Simple sentense like "Use of I= P=20 encapsulation may introduce Layer 3 defects that be positive negatives to= =20 monitored LAG." would be sufficient IMHO.
 
        Regards,
           &n= bsp;   =20 Greg
 
-----Original Message-----
From: Manav Bhatia [mailto:manav.bhatia@alcatel-lucent.com]= =20
Sent: Tuesday, July 10, 2012 11:43= =20 PM
To: Gregory Mirsky
Cc: rtg-bfd@ietf.org
Subject: Re: Comments on=20 draft-mmm-bfd-on-lags-05.txt
 
Hi Gregory,
 
> GIM>>>> No, I'm no= t=20 suggesting not to use IP encapsulation of BFD but
> I'm suggesting thoroughly docu= ment=20 what could be implications of using
> IP encapsulation of BFD to mon= itor=20 Layer 2 path.
 
Sure this should be done. We can ta= ke it=20 up as an additional draft so that we dont stall the progress of this one.= This=20 is precisely why we kept the mechanism to dynamically learn the remote IP= =20 addresses in a separate draft=20 (draft-mmsn-bfd-on-lags-address-00.txt).
 
We can also later explore the possi= bility=20 of merging these drafts into the main draft, if thats the WG consensus=20 then.
 
> I would wager that the entry a= nd exit=20 criteron for micro BFD would be
> the same as the regular rfc 58= 81 BFD.=20 Why would this be any different?
>
> GIM>>>> As I've no= ted=20 earlier, many BFD related document use term
> "connectivity" when in fact=20 discussing "continuity". But these are not
> the same, not identical. If th= e draft=20 we're discussing uses
> "connectivity" in place=20 of"continuity", then a note with explanation
> should, IMHO, suffice. But if= =20 intention is to go beyond RFC 5880 and
> monitor connectivity, then=20 mis-connection defects have to be defined.
 
Would s/connectivity/continuity hel= p?=20 :-)
 
Cheers, Manav
 
--_000_7C362EEF9C7896468B36C9B79200D8350D0615BC47INBANSXCHMBSA_-- From marc@sniff.de Mon Jul 16 03:31: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 2591F21F87B3 for ; Mon, 16 Jul 2012 03:31:08 -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 fkd42ZMZINGs for ; Mon, 16 Jul 2012 03:31:07 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5218A21F86CF for ; Mon, 16 Jul 2012 03:31:07 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 57D0A2AA0F; Mon, 16 Jul 2012 10:31:50 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Fwd: I-D Action: draft-akiya-bfd-intervals-03.txt From: Marc Binderberger Date: Mon, 16 Jul 2012 12:31:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120716102532.2738.60203.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org X-Mailer: Apple Mail (2.1084) 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, 16 Jul 2012 10:31:08 -0000 Hello BFD experts, Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, = mainly fixing some typos and adding one clarification. We received (unicast) several feedbacks, in general positive. What still = may require a closer look is: (i) the set of Standard Interval values (ii) the Poll/Final sequence example in Appendix B Thanks & Regards, Marc Begin forwarded message: > From: internet-drafts@ietf.org > Date: July 16, 2012 12:25:32 GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-akiya-bfd-intervals-03.txt > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Standardized interval support in BFD > Author(s) : Nobo Akiya > Marc Binderberger > Filename : draft-akiya-bfd-intervals-03.txt > Pages : 8 > Date : 2012-07-16 >=20 > Abstract: > This document defines a set of interval values that we call = "Standard > intervals". Values of this set must be supported for transmitting > BFD control packets and for calculating the detection time in the > receive direction when the value is equal or larger than the = fastest, > i.e. lowest, interval a particular BFD implementation supports. >=20 > This solves the problem of finding an interval value that both BFD > speakers can support while allowing a simplified implementation as > seen for hardware-based BFD. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-akiya-bfd-intervals >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 >=20 > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-intervals-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Marc Binderberger From muly_i@rad.com Mon Jul 16 07:07:53 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 59F6211E80C2 for ; Mon, 16 Jul 2012 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.207, 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 5Fpm7qqaofXG for ; Mon, 16 Jul 2012 07:07:51 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52221F8853 for ; Mon, 16 Jul 2012 07:07:50 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 16 Jul 2012 16:32:47 +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; Mon, 16 Jul 2012 17:08:32 +0300 From: Muly Ilan To: "rtg-bfd@ietf.org" Subject: Comments to draft-ietf-bfd-mpls-mib-00 Thread-Topic: Comments to draft-ietf-bfd-mpls-mib-00 Thread-Index: Ac1jXChrF993WQmUQo+moecU0wDumgAACuow Date: Mon, 16 Jul 2012 14:08:32 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87042C799D@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_32CB7A1F0806AB4688CE3F22C29DAC87042C799DEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090208.50042062.0016,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: Mon, 16 Jul 2012 14:07:53 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC87042C799DEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 1. In section 5.2.2, Example of BFD Session configuration for Maintenance Enti= ty of MPLS-TP TE tunnel, the object mplsOamIdMeProactiveOamSessIndex of the= ME table in draft-vkst-mpls-tp-oam-id-mib is not mentioned. It would be helpful to explain that when a BFD session with bfdMplsSessMapT= ype=3Dmep(6) is created in the bfdSessTable, the value of the object mplsOa= mIdMeProactiveOamSessIndex should be updated with the BFD session index. 2. For the associated bidirectional LSPs case there would be two unidirectiona= l MEs that together operate the BFD session. To which one of the MEs should= the map pointer, bfdMplsSessMapPointer, point? I think it may point to either one of the unidirectional MEs i.e. make it i= mplementation specific, but this should be described in the MIB. 3. The term "session mode" in RFC6428 refers to coordinated operation vs. inde= pendent operation. However the current object bfdMplsSessMode sets the BFD = functionality to cc(1) or cv(2). Suggest to rename the object to bfdMplsSes= sFunction. 4. There's a need to configure what is the consequent action upon mis-connecti= vity defect and LOC defect. Possible values: alarm only, alarm and block da= ta. Separate configuration for mis-connectivity and for LOC. Default value for = mis-connectivity is alarm and block data. Default value for LOC is alarm on= ly. Maybe a common behavior for all BFD sessions is sufficient. In this case de= fine two scalar objects. 5. Suggest to add counters for received and transmitted CC and CV packets. Nee= d separate counters for CC and CV. Regards, Muly --_000_32CB7A1F0806AB4688CE3F22C29DAC87042C799DEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

1.

In section 5.2.2, Example of BFD Session configurati= on for Maintenance Entity of MPLS-TP TE tunnel, the object mplsOamIdMeProac= tiveOamSessIndex of the ME table in draft-vkst-mpls-tp-oam-id-mib is not me= ntioned.

It would be helpful to explain that when a BFD sessi= on with bfdMplsSessMapType=3Dmep(6) is created in the bfdSessTable, the val= ue of the object mplsOamIdMeProactiveOamSessIndex should be updated with th= e BFD session index.

 

2.

For the associated bidirectional LSPs case there wou= ld be two unidirectional MEs that together operate the BFD session. To whic= h one of the MEs should the map pointer, bfdMplsSessMapPointer, point?=

I think it may point to either one of the unidirecti= onal MEs i.e. make it implementation specific, but this should be described= in the MIB.

 

3.

The term “session mode” in RFC6428 refer= s to coordinated operation vs. independent operation. However the current o= bject bfdMplsSessMode sets the BFD functionality to cc(1) or cv(2). Suggest= to rename the object to bfdMplsSessFunction.

 

4.

There’s a need to configure what is the conseq= uent action upon mis-connectivity defect and LOC defect. Possible values: a= larm only, alarm and block data.

Separate configuration for mis-connectivity and for = LOC. Default value for mis-connectivity is alarm and block data. Default va= lue for LOC is alarm only.

Maybe a common behavior for all BFD sessions is suff= icient. In this case define two scalar objects.

 

5.

Suggest to add counters for received and transmitted= CC and CV packets. Need separate counters for CC and CV.

 

 

Regards,

 

Muly

--_000_32CB7A1F0806AB4688CE3F22C29DAC87042C799DEXRAD5adradcoil_-- From toms.sanders@gmail.com Mon Jul 16 08:50:21 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 CC85E21F86FC for ; Mon, 16 Jul 2012 08:50:21 -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 c1khr1f8KrQF for ; Mon, 16 Jul 2012 08:50:21 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2F21F86A8 for ; Mon, 16 Jul 2012 08:50:20 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so2514574wgb.1 for ; Mon, 16 Jul 2012 08:51:05 -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=pxFaIfWTUGt4WnCSpuvJom3QayrJ3tdcqCtLKKxZMAM=; b=XcuyxnxgjFmr8z2yCx5d/uG2heZj5WFKupFfB4mqPAIHJG6htWpl65f/1ojZ9QspX6 7MK8RNkNWXJEZ77jwCB+mkGnXleQ/uart2vnwX1euBpRN5Oyxb9wGdaD08EoPCkkiLGe MgQIsQJEYG3BLcM8kW+xo4jEQCo99kUBb2hvX3HHrUrURZKe5ObwwfNkQEF0dS25+t2G NGMzcMCT8Zm2t4lVZTqw0iSv/ARm1BR1nbFzB8pxPRVpac4LJ1Vn7Dk8ahXMSxH8lIoO 099bJV+aWZDnFOa5GMvCT491WA/6f6yxH0Iw8Sa4j3mWKRmECzgSKsGxwfmwJYnefiIi 0Phg== MIME-Version: 1.0 Received: by 10.180.102.136 with SMTP id fo8mr19165548wib.19.1342453864980; Mon, 16 Jul 2012 08:51:04 -0700 (PDT) Received: by 10.223.194.72 with HTTP; Mon, 16 Jul 2012 08:51:04 -0700 (PDT) In-Reply-To: <4FFBB348.6030608@alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D0615B254@INBANSXCHMBSA1.in.alcatel-lucent.com> <4FFBB348.6030608@alcatel-lucent.com> Date: Mon, 16 Jul 2012 21:21:04 +0530 Message-ID: Subject: Re: BFD over LAGs updated From: Tom Sanders To: Manav Bhatia Content-Type: text/plain; charset=UTF-8 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: Mon, 16 Jul 2012 15:50:22 -0000 Thanks Manav. This answers my question. Is there any consensus on the mechanism (multicast or 127/8) that will be used for remote IP discovery? Toms On 10 July 2012 10:14, Manav Bhatia wrote: > Hi Toms, > > The IP address of the remote end needs to be explicitly configured. > > If you dont want to manually configure the IP addresses then you can look at > draft-mmsn-bfd-on-lags-address-00.txt to see how this IP address can be > dynamically discovered. > > Cheers, Manav > > > On 7/9/2012 8:53 PM, Tom Sanders wrote: >> >> Hi Manav, >> >> I understand that micro BFD session packets go with unicast ip >> addresses. The question is that how will i figure out the IP to fill >> in the micro BFD packets? >> >> Toms >> >> On 7 July 2012 05:11, Bhatia, Manav (Manav) >> wrote: >>> >>> Hi, >>> >>> We have posted an updated version of BFD over LAGs. >>> >>> http://www.ietf.org/id/draft-mmm-bfd-on-lags-05.txt >>> >>> Diff from the last version: >>> http://tools.ietf.org/rfcdiff?url2=draft-mmm-bfd-on-lags-05 >>> >>> Would appreciate if the WG members can review this version and provide >>> feedback. >>> >>> Cheers, Manav >> >> >> >> > -- Toms. From venkatflex@gmail.com Tue Jul 17 22:40:37 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 DF74011E811B; Tue, 17 Jul 2012 22:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 AuM6w-VGaZHT; Tue, 17 Jul 2012 22:40:37 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA3DD11E80AE; Tue, 17 Jul 2012 22:40:36 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so905429vcb.31 for ; Tue, 17 Jul 2012 22:41:25 -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:cc:content-type; bh=P7rBDLA/xbfUXi13Uwok83Yp2Ppt3zbB7YhCIKnzeus=; b=wTTqHr8UIxFXf24Axihjc9sgwxBCVO/urhAfYB8YeYZi3K7yLuxBatzQAhfE1nfQHy cor5/K6baOX/M2br0KfcselEhJ0Jfh0Y78K8nuRSych8NxCRgbG7vlcm7EW+lWY+3wVL IIEWAzWn3evGxXLI1BaA8AIkKhlBDKyPFgEIZcYxa7USquX4IilmgiE4DGWVdr8IVp8t bdLGqnnwz+oScoRw1tYv1iZU23dVTP0Ywf4+5QBetgHiKPjTGj92fHDPXdpD1SWBsVcS 0Lb+rqLXgBXaf3spb1AzWyLRFM674z8lfww0ceF6Nw7HLAsDKsfZYqMREGwF0/qlRVrT jysQ== MIME-Version: 1.0 Received: by 10.220.224.77 with SMTP id in13mr2876937vcb.9.1342590085022; Tue, 17 Jul 2012 22:41:25 -0700 (PDT) Received: by 10.220.32.14 with HTTP; Tue, 17 Jul 2012 22:41:24 -0700 (PDT) Date: Tue, 17 Jul 2012 22:41:24 -0700 Message-ID: Subject: Re: Comments to draft-ietf-bfd-mpls-mib-00 From: venkatesan mahalingam To: Muly Ilan Content-Type: multipart/alternative; boundary=14dae9cdc47d18c3f004c5141d6d Cc: mpls , rtg-bfd@ietf.org, Kannan KV Sampath , Sam Aldrin , Thomas Nadeau 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, 18 Jul 2012 05:40:38 -0000 --14dae9cdc47d18c3f004c5141d6d Content-Type: text/plain; charset=ISO-8859-1 Thanks Muly for your comments, please see my answers inlined with the tag [VM]. Cheers, Venkat. Date: Mon, 16 Jul 2012 14:08:32 +0000 From: Muly Ilan To: "rtg-bfd@ietf.org" Subject: Comments to draft-ietf-bfd-mpls-mib-00 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87042C799D@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset="us-ascii" Hi, 1. In section 5.2.2, Example of BFD Session configuration for Maintenance Entity of MPLS-TP TE tunnel, the object mplsOamIdMeProactiveOamSessIndex of the ME table in draft-vkst-mpls-tp-oam-id-mib is not mentioned. It would be helpful to explain that when a BFD session with bfdMplsSessMapType=mep(6) is created in the bfdSessTable, the value of the object mplsOamIdMeProactiveOamSessIndex should be updated with the BFD session index. [VM] OK 2. For the associated bidirectional LSPs case there would be two unidirectional MEs that together operate the BFD session. To which one of the MEs should the map pointer, bfdMplsSessMapPointer, point? I think it may point to either one of the unidirectional MEs i.e. make it implementation specific, but this should be described in the MIB. [VM] This draft suggests to map each ME of LSP/PW entry with the BFD session entry, for associated bidirectional case, having an BFD session entry to point to either one of the unidirectional ME is purely implementation specific, IMO, nothing needs to be described. 3. The term "session mode" in RFC6428 refers to coordinated operation vs. independent operation. However the current object bfdMplsSessMode sets the BFD functionality to cc(1) or cv(2). Suggest to rename the object to bfdMplsSessFunction. [VM] IMO,MIB object for coordinated & independent session mode operation is not required as we can infer it from bfd.MinRxInterval value 0. bfdMplsSessMode denotes the BFD message format (CC/CV) to be carried in the BFD control packet, IMO this MIB object should be retained. if this MIB object name does not convey the right meaning, we might need to choose appropriate MIB object name. 4. There's a need to configure what is the consequent action upon mis-connectivity defect and LOC defect. Possible values: alarm only, alarm and block data. Separate configuration for mis-connectivity and for LOC. Default value for mis-connectivity is alarm and block data. Default value for LOC is alarm only. Maybe a common behavior for all BFD sessions is sufficient. In this case define two scalar objects. [VM] OK 5. Suggest to add counters for received and transmitted CC and CV packets. Need separate counters for CC and CV. [VM] OK Regards, Muly --14dae9cdc47d18c3f004c5141d6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Muly for your comments, please see my answers inlined= with the tag [VM].

Cheers,
Venkat.
Date: Mon, 16 Jul 2012 = 14:08:32 +0000
From: Muly Ilan <muly_i@rad.com= >
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Comments to draft-ietf-bfd-= mpls-mib-00
Message-ID:
=A0 =A0 =A0 =A0 <32CB7A1F0806AB4688CE3F22C29DAC87042C799D@EX= RAD5.ad.rad.co.il>
Content-Type: text/plain; charset=3D= "us-ascii"

Hi,

1.
In section 5.2.2, Example of BFD Ses= sion configuration for Maintenance Entity of MPLS-TP TE tunnel, the object = mplsOamIdMeProactiveOamSessIndex of the ME table in draft-vkst-mpls-tp-oam-id-mib is not mentioned.
It would be helpful to explain that = when a BFD session with bfdMplsSessMapType=3Dmep(6) is created in the bfdSe= ssTable, the value of the object mplsOamIdMeProactiveOamSessIndex should be updated with the BFD session= index.

[VM] OK

2.
For the associated bidirectional LSP= s case there would be two unidirectional MEs that together operate the BFD = session. To which one of the MEs should the map pointer, bfdMplsSessMapPoin= ter, point?
I think it may point to either one o= f the unidirectional MEs i.e. make it implementation specific, but this sho= uld be described in the MIB.
[VM] This draft suggests to map each ME of LSP/PW entry with the BFD sessio= n entry, for associated bidirectional case, having an BFD session entry to = point to either one of the unidirectional ME is purely implementation speci= fic, IMO, nothing needs to be described.

3.
The term "session mode" in= RFC6428 refers to coordinated operation vs. independent operation. However= the current object bfdMplsSessMode sets the BFD functionality to cc(1) or = cv(2). Suggest to rename the object to bfdMplsSessFunction.
[VM] IMO,MIB object for coordinated & independent session mode ope= ration is not required as we can infer it from bfd.MinRxInterval value 0.
bfdMplsSessMode denotes the BFD message format (CC/CV) to be carried in the=
 BFD control packet, IMO this MIB object should be retained.
if t=
his MIB object name does not convey the right meaning, we might need to cho=
ose appropriate MIB object name.

4.
There's a need to configure what= is the consequent action upon mis-connectivity defect and LOC defect. Poss= ible values: alarm only, alarm and block data.
Separate configuration for mis-conne= ctivity and for LOC. Default value for mis-connectivity is alarm and block = data. Default value for LOC is alarm only.
Maybe a common behavior for all BFD = sessions is sufficient. In this case define two scalar objects.
[VM] OK

5.
Suggest to add counters for received= and transmitted CC and CV packets. Need separate counters for CC and CV.
[VM] OK

Regards,

Muly
--14dae9cdc47d18c3f004c5141d6d-- From muly_i@rad.com Thu Jul 19 01:57:36 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 59E1321F86EB for ; Thu, 19 Jul 2012 01:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 UL2sv9FdSE7I for ; Thu, 19 Jul 2012 01:57:33 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3E03521F86F2 for ; Thu, 19 Jul 2012 01:57:31 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 19 Jul 2012 11:37:37 +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; Thu, 19 Jul 2012 11:58:20 +0300 From: Muly Ilan To: venkatesan mahalingam Subject: RE: Comments to draft-ietf-bfd-mpls-mib-00 Thread-Topic: Comments to draft-ietf-bfd-mpls-mib-00 Thread-Index: AQHNZKf3F993WQmUQo+moecU0wDumpcwSBvw Date: Thu, 19 Jul 2012 08:58:20 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87042C81AD@EXRAD5.ad.rad.co.il> References: In-Reply-To: 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_32CB7A1F0806AB4688CE3F22C29DAC87042C81ADEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0B0205.5007CC2D.0166,ss=1,fgs=0 Cc: mpls , "rtg-bfd@ietf.org" , Kannan KV Sampath , Sam Aldrin , Thomas Nadeau 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, 19 Jul 2012 08:57:36 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC87042C81ADEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Venkat., Regarding the 3rd issue, of "session mode". I haven't requested to define a= MIB object for the coordinated/independent modes. I merely suggested to rename "bfdMplsSessMode" to "bfdMplsSessFunction" to = avoid misunderstandings. Muly From: venkatesan mahalingam [mailto:venkatflex@gmail.com] Sent: Wednesday, July 18, 2012 8:41 AM To: Muly Ilan Cc: rtg-bfd@ietf.org; mpls; Kannan KV Sampath; Sam Aldrin; Thomas Nadeau Subject: Re: Comments to draft-ietf-bfd-mpls-mib-00 Thanks Muly for your comments, please see my answers inlined with the tag [= VM]. Cheers, Venkat. Date: Mon, 16 Jul 2012 14:08:32 +0000 From: Muly Ilan > To: "rtg-bfd@ietf.org" > Subject: Comments to draft-ietf-bfd-mpls-mib-00 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87042C799D@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=3D"us-ascii" Hi, 1. In section 5.2.2, Example of BFD Session configuration for Maintenance Enti= ty of MPLS-TP TE tunnel, the object mplsOamIdMeProactiveOamSessIndex of the= ME table in draft-vkst-mpls-tp-oam-id-mib is not mentioned. It would be helpful to explain that when a BFD session with bfdMplsSessMapT= ype=3Dmep(6) is created in the bfdSessTable, the value of the object mplsOa= mIdMeProactiveOamSessIndex should be updated with the BFD session index. [VM] OK 2. For the associated bidirectional LSPs case there would be two unidirectiona= l MEs that together operate the BFD session. To which one of the MEs should= the map pointer, bfdMplsSessMapPointer, point? I think it may point to either one of the unidirectional MEs i.e. make it i= mplementation specific, but this should be described in the MIB. [VM] This draft suggests to map each ME of LSP/PW entry with the BFD sessio= n entry, for associated bidirectional case, having an BFD session entry to = point to either one of the unidirectional ME is purely implementation speci= fic, IMO, nothing needs to be described. 3. The term "session mode" in RFC6428 refers to coordinated operation vs. inde= pendent operation. However the current object bfdMplsSessMode sets the BFD = functionality to cc(1) or cv(2). Suggest to rename the object to bfdMplsSes= sFunction. [VM] IMO,MIB object for coordinated & independent session mode operation is= not required as we can infer it from bfd.MinRxInterval value 0. bfdMplsSessMode denotes the BFD message format (CC/CV) to be carried in the= BFD control packet, IMO this MIB object should be retained. if this MIB object name does not convey the right meaning, we might need to= choose appropriate MIB object name. 4. There's a need to configure what is the consequent action upon mis-connecti= vity defect and LOC defect. Possible values: alarm only, alarm and block da= ta. Separate configuration for mis-connectivity and for LOC. Default value for = mis-connectivity is alarm and block data. Default value for LOC is alarm on= ly. Maybe a common behavior for all BFD sessions is sufficient. In this case de= fine two scalar objects. [VM] OK 5. Suggest to add counters for received and transmitted CC and CV packets. Nee= d separate counters for CC and CV. [VM] OK Regards, Muly --_000_32CB7A1F0806AB4688CE3F22C29DAC87042C81ADEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Venkat.,

 <= /p>

Regarding the 3rd issue, of “session mode”. I haven’t requested to defi= ne a MIB object for the coordinated/independent modes.

I merely suggested to ren= ame “bfdMplsSessMode= ” to “bfdMplsSessFunction” to avoid misunderstandings.

 = ;

Muly

 <= /p>

From: venkates= an mahalingam [mailto:venkatflex@gmail.com]
Sent: Wednesday, July 18, 2012 8:41 AM
To: Muly Ilan
Cc: rtg-bfd@ietf.org; mpls; Kannan KV Sampath; Sam Aldrin; Thomas Na= deau
Subject: Re: Comments to draft-ietf-bfd-mpls-mib-00

 

 

Thanks Muly for your comments, please see my answers= inlined with the tag [VM].

 

Cheers,

Venkat.

 

Date: Mon,= 16 Jul 2012 14:08:32 +0000
From: Muly Ilan <muly_i= @rad.com>
To: "rtg-bfd@ietf.or= g" <rtg-bfd@ietf.org>
Subject: Comments to draft-ietf-bfd-mpls-m= ib-00
Message-ID:
        <32CB7A1F0806AB4688CE3F22= C29DAC87042C799D@EXRAD5.ad.rad.co.il>
Content-Type: text/plain; charset=3D"= us-ascii"

Hi,

1.
In section 5.2.2, Example of BFD Session c= onfiguration for Maintenance Entity of MPLS-TP TE tunnel, the object mplsOa= mIdMeProactiveOamSessIndex of the ME table in draft-vkst-mpls-tp-oam-id-mib= is not mentioned.
It would be helpful to explain that when a= BFD session with bfdMplsSessMapType=3Dmep(6) is created in the bfdSessTabl= e, the value of the object mplsOamIdMeProactiveOamSessIndex should be updat= ed with the BFD session index.

[VM] OK


2.
For the associated bidirectional LSPs case= there would be two unidirectional MEs that together operate the BFD sessio= n. To which one of the MEs should the map pointer, bfdMplsSessMapPointer, p= oint?
I think it may point to either one of the = unidirectional MEs i.e. make it implementation specific, but this should be= described in the MIB.
[VM] This draft suggests to map each ME of LSP/PW entry with the BFD= session entry, for associated bidirectional case, having an BFD session en= try to point to either one of the unidirectional ME is purely implementatio= n specific, IMO, nothing needs to be described.


3.
The term "session mode" in RFC64= 28 refers to coordinated operation vs. independent operation. However the c= urrent object bfdMplsSessMode sets the BFD functionality to cc(1) or cv(2).= Suggest to rename the object to bfdMplsSessFunction.

[VM] IMO,MIB object for coordinated & independen= t session mode operation is not required as we can infer it from bfd.MinRxI= nterval value 0.

 
bfdMplsSessMode denotes the BFD messa=
ge format (CC/CV) to be carried in the BFD control packet, IMO this MIB obj=
ect should be retained.
if this MIB object name does not conv=
ey the right meaning, we might need to choose appropriate MIB object name.<=
o:p>


4.
There's a need to configure what is the co= nsequent action upon mis-connectivity defect and LOC defect. Possible value= s: alarm only, alarm and block data.
Separate configuration for mis-connectivit= y and for LOC. Default value for mis-connectivity is alarm and block data. = Default value for LOC is alarm only.
Maybe a common behavior for all BFD sessio= ns is sufficient. In this case define two scalar objects.
[VM] OK


5.
Suggest to add counters for received and t= ransmitted CC and CV packets. Need separate counters for CC and CV.<= br> [VM] OK

Regards,

Muly

--_000_32CB7A1F0806AB4688CE3F22C29DAC87042C81ADEXRAD5adradcoil_-- From venkatflex@gmail.com Thu Jul 19 12:32: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 C899421F877A; Thu, 19 Jul 2012 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 fd1rIQJQ569L; Thu, 19 Jul 2012 12:32:22 -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 9C39D21F877B; Thu, 19 Jul 2012 12:32:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2537438vbb.31 for ; Thu, 19 Jul 2012 12:33:10 -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=nHN/gE2RnK1qegbfJDEr9CDlaosFIGgzHC5gPvebAB8=; b=oMgH5aQvhRLix7/lVwfBvgKKqtXZ53bez08BgYI1rcFnUN2+RalIulHB9++pRyWpmE Ji63fCGZmd+3B9DlVBPd6f6u4KMUEHeGV6hyu1QSwSJBhN1HE4efHx9ZmPH3RA4Rv4V7 nEsqXWhi7KSl2Vbdzj3lHKZ8firJxN68YWwrfCn2iIIexZthe36j16tyPkm5+ofsF3n5 NOsLxNstxd7XJ6NJCh4xLRc+NxR5QaMXDIEtCxL8wHGSi9bMKHCY+e2tGwPvgw8LZvC+ HFhS1myFUffF94bXpsLO2u+ZPOuFZ+wb4JV1ofwoYoV/XIpUv3nRch4AHehecly+Ll4z dj2A== MIME-Version: 1.0 Received: by 10.220.8.17 with SMTP id f17mr2037022vcf.11.1342726390366; Thu, 19 Jul 2012 12:33:10 -0700 (PDT) Received: by 10.220.32.14 with HTTP; Thu, 19 Jul 2012 12:33:10 -0700 (PDT) In-Reply-To: <32CB7A1F0806AB4688CE3F22C29DAC87042C81AD@EXRAD5.ad.rad.co.il> References: <32CB7A1F0806AB4688CE3F22C29DAC87042C81AD@EXRAD5.ad.rad.co.il> Date: Thu, 19 Jul 2012 12:33:10 -0700 Message-ID: Subject: Re: Comments to draft-ietf-bfd-mpls-mib-00 From: venkatesan mahalingam To: Muly Ilan Content-Type: multipart/alternative; boundary=bcaec54ee5988740f004c533d9a5 Cc: mpls , "rtg-bfd@ietf.org" , Kannan KV Sampath , Sam Aldrin , Thomas Nadeau 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, 19 Jul 2012 19:32:24 -0000 --bcaec54ee5988740f004c533d9a5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, thanks Muly. Cheers, Venkat. On Thu, Jul 19, 2012 at 1:58 AM, Muly Ilan wrote: > Hi Venkat.,**** > > ** ** > > Regarding the 3rd issue, of =93session mode=94. I haven=92t requested to = define > a MIB object for the coordinated/independent modes.**** > > I merely suggested to rename =93bfdMplsSessMode=94 to =93bfdMplsSessFunct= ion=94 > to avoid misunderstandings.**** > > ** ** > > Muly**** > > ** ** > > *From:* venkatesan mahalingam [mailto:venkatflex@gmail.com] > *Sent:* Wednesday, July 18, 2012 8:41 AM > *To:* Muly Ilan > *Cc:* rtg-bfd@ietf.org; mpls; Kannan KV Sampath; Sam Aldrin; Thomas Nadea= u > *Subject:* Re: Comments to draft-ietf-bfd-mpls-mib-00**** > > ** ** > > ** ** > > Thanks Muly for your comments, please see my answers inlined with the tag > [VM].**** > > ** ** > > Cheers,**** > > Venkat.**** > > ** ** > > Date: Mon, 16 Jul 2012 14:08:32 +0000 > From: Muly Ilan > To: "rtg-bfd@ietf.org" > Subject: Comments to draft-ietf-bfd-mpls-mib-00 > Message-ID: > <32CB7A1F0806AB4688CE3F22C29DAC87042C799D@EXRAD5.ad.rad.co.il> > Content-Type: text/plain; charset=3D"us-ascii" > > Hi, > > 1. > In section 5.2.2, Example of BFD Session configuration for Maintenance > Entity of MPLS-TP TE tunnel, the object mplsOamIdMeProactiveOamSessIndex = of > the ME table in draft-vkst-mpls-tp-oam-id-mib is not mentioned. > It would be helpful to explain that when a BFD session with > bfdMplsSessMapType=3Dmep(6) is created in the bfdSessTable, the value of = the > object mplsOamIdMeProactiveOamSessIndex should be updated with the BFD > session index. > > [VM] OK**** > > > 2. > For the associated bidirectional LSPs case there would be two > unidirectional MEs that together operate the BFD session. To which one of > the MEs should the map pointer, bfdMplsSessMapPointer, point? > I think it may point to either one of the unidirectional MEs i.e. make it > implementation specific, but this should be described in the MIB. > [VM] This draft suggests to map each ME of LSP/PW entry with the BFD > session entry, for associated bidirectional case, having an BFD session > entry to point to either one of the unidirectional ME is purely > implementation specific, IMO, nothing needs to be described.**** > > > 3. > The term "session mode" in RFC6428 refers to coordinated operation vs. > independent operation. However the current object bfdMplsSessMode sets th= e > BFD functionality to cc(1) or cv(2). Suggest to rename the object to > bfdMplsSessFunction.**** > > [VM] IMO,MIB object for coordinated & independent session mode operation > is not required as we can infer it from bfd.MinRxInterval value 0.**** > > ** ** > > bfdMplsSessMode denotes the BFD message format (CC/CV) to be carried in t= he BFD control packet, IMO this MIB object should be retained.**** > > if this MIB object name does not convey the right meaning, we might need = to choose appropriate MIB object name.**** > > > 4. > There's a need to configure what is the consequent action upon > mis-connectivity defect and LOC defect. Possible values: alarm only, alar= m > and block data. > Separate configuration for mis-connectivity and for LOC. Default value fo= r > mis-connectivity is alarm and block data. Default value for LOC is alarm > only. > Maybe a common behavior for all BFD sessions is sufficient. In this case > define two scalar objects. > [VM] OK**** > > > 5. > Suggest to add counters for received and transmitted CC and CV packets. > Need separate counters for CC and CV. > [VM] OK > > Regards, > > Muly **** > --bcaec54ee5988740f004c533d9a5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, thanks Muly.

Cheers,
Venkat.

On Thu, Jul 19, 2012 at 1:58 AM, Muly Ilan <muly_i@rad= .com> wrote:

Hi Venkat.,=

=A0<= /p>

Regarding the 3rd issue, of =93session mode=94. I haven=92t requested to define a MIB obj= ect for the coordinated/independent modes.

I merely suggested to ren= ame =93bfdMplsSessMode=94 = to =93bfdMplsSessFunction=94 to avoid misunderstandings.

=A0=

Muly

=A0<= /p>

From: venkates= an mahalingam [mailto:venkatflex@gmail.com]
Sent: Wednesday, July 18, 2012 8:41 AM
To: Muly Ilan
Cc: rtg-bfd@ie= tf.org; mpls; Kannan KV Sampath; Sam Aldrin; Thomas Nadeau
Subject: Re: Comments to draft-ietf-bfd-mpls-mib-00

=A0

=A0

Thanks Muly for your comments, please see my answers= inlined with the tag [VM].

=A0

Cheers,

Venkat.

=A0

Date: Mon,= 16 Jul 2012 14:08:32 +0000
From: Muly Ilan <muly_i@rad.com>
To: "rtg-bfd@ietf.org&qu= ot; <rtg-bfd@ietf.org>
Subject: Comments to draft-ietf-bfd-mpls-m= ib-00
Message-ID:
=A0 =A0 =A0 =A0 <32CB7A1F0806AB468= 8CE3F22C29DAC87042C799D@EXRAD5.ad.rad.co.il>
Content-Type: text/plain; charset=3D"= us-ascii"

Hi,

1.
In section 5.2.2, Example of BFD Session c= onfiguration for Maintenance Entity of MPLS-TP TE tunnel, the object mplsOa= mIdMeProactiveOamSessIndex of the ME table in draft-vkst-mpls-tp-oam-id-mib= is not mentioned.
It would be helpful to explain that when a= BFD session with bfdMplsSessMapType=3Dmep(6) is created in the bfdSessTabl= e, the value of the object mplsOamIdMeProactiveOamSessIndex should be updat= ed with the BFD session index.

[VM] OK


2.
For the associated bidirectional LSPs case= there would be two unidirectional MEs that together operate the BFD sessio= n. To which one of the MEs should the map pointer, bfdMplsSessMapPointer, p= oint?
I think it may point to either one of the = unidirectional MEs i.e. make it implementation specific, but this should be= described in the MIB.
[VM] This draft suggests to map each ME of LSP/PW entry with the BFD= session entry, for associated bidirectional case, having an BFD session en= try to point to either one of the unidirectional ME is purely implementatio= n specific, IMO, nothing needs to be described.


3.
The term "session mode" in RFC64= 28 refers to coordinated operation vs. independent operation. However the c= urrent object bfdMplsSessMode sets the BFD functionality to cc(1) or cv(2).= Suggest to rename the object to bfdMplsSessFunction.<= u>

[VM] IMO,MIB object for coordinated & independen= t session mode operation is not required as we can infer it from bfd.MinRxI= nterval value 0.

=A0
bfdMplsSessMode denotes the BFD messa=
ge format (CC/CV) to be carried in the BFD control packet, IMO this MIB obj=
ect should be retained.
if this MIB object name does not conv=
ey the right meaning, we might need to choose appropriate MIB object name.<=
u>


4.
There's a need to configure what is th= e consequent action upon mis-connectivity defect and LOC defect. Possible v= alues: alarm only, alarm and block data.
Separate configuration for mis-connectivit= y and for LOC. Default value for mis-connectivity is alarm and block data. = Default value for LOC is alarm only.
Maybe a common behavior for all BFD sessio= ns is sufficient. In this case define two scalar objects.
[VM] OK


5.
Suggest to add counters for received and t= ransmitted CC and CV packets. Need separate counters for CC and CV.<= br> [VM] OK

Regards,

Muly


--bcaec54ee5988740f004c533d9a5-- From gregimirsky@gmail.com Tue Jul 24 16:34:17 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 D2B2311E80BC for ; Tue, 24 Jul 2012 16:34:17 -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 rMpyDZBCqP+R for ; Tue, 24 Jul 2012 16:34:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F166A11E809B for ; Tue, 24 Jul 2012 16:34:16 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so181653obb.31 for ; Tue, 24 Jul 2012 16:34:16 -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=UWxK/aXEOinveLFqfYQP6V7QQ9fl7FKsgG/zctkxaGw=; b=rqPJXBI4YNRqSoT94GKa+5NmzBs+s23zkZZxPP0vcKMXxEft+1vw+/5d+1HljH5Weh RKp7r9xmGzT071jY0gxOEfJwISqrjoFof8vOxLeD+jYLMcHjjf40Ct1hFvgzI/vKXCdS V239zFvYMFa1WVP6GmjlLltcUyQm/SbWQshlQbDki+rRpQVwzjBGtaXSu/DoNXa/xPJ5 OpavMcXlvIYxe3Tuo8v3OPj5tAOn+mZ8VcGfyKFxV1kQE35cOgYCRlIr0qi9DqDpucwR t53q+Az32HjvRPA9SkOan7sVhMHDBq1NjCvv7vp8GB+q5w7AnD2kUH1pxZ9qCUu8fa3l 8Jxw== MIME-Version: 1.0 Received: by 10.60.169.134 with SMTP id ae6mr30669758oec.55.1343172856524; Tue, 24 Jul 2012 16:34:16 -0700 (PDT) Received: by 10.182.220.34 with HTTP; Tue, 24 Jul 2012 16:34:16 -0700 (PDT) In-Reply-To: References: <20120716102532.2738.60203.idtracker@ietfa.amsl.com> Date: Tue, 24 Jul 2012 16:34:16 -0700 Message-ID: Subject: Re: I-D Action: draft-akiya-bfd-intervals-03.txt From: Greg Mirsky To: Marc Binderberger Content-Type: multipart/alternative; boundary=bcaec550b36cfc2ef504c59bcc4e 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, 24 Jul 2012 23:34:18 -0000 --bcaec550b36cfc2ef504c59bcc4e Content-Type: text/plain; charset=ISO-8859-1 Hi Marc, et al., I think I'd refer to the set of timer values defined in the draft-akiya-bfd-intervals as 'Minimally Required Set" rather than as "Standard". Second, 3.3 ms interval included in the set for the benefit of MPLS-TP. I'd note that OAM for packet transport networks would likely to use from set of intervals defined in IEEE 802.1ag/Y.1731, i.e. [3.3 ms, 10 ms, 100 ms, 1 sec, 10 sec, 1 min, 10 min]. To make two sets more compatible, I propose to include 100 ms interval into the Minimally Required Set that proposed in the draft. Regards, Greg On Mon, Jul 16, 2012 at 3:31 AM, Marc Binderberger wrote: > Hello BFD experts, > > Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, > mainly fixing some typos and adding one clarification. > > We received (unicast) several feedbacks, in general positive. What still > may require a closer look is: > > (i) the set of Standard Interval values > > (ii) the Poll/Final sequence example in Appendix B > > > Thanks & Regards, > Marc > > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Date: July 16, 2012 12:25:32 GMT+02:00 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-akiya-bfd-intervals-03.txt > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Standardized interval support in BFD > > Author(s) : Nobo Akiya > > Marc Binderberger > > Filename : draft-akiya-bfd-intervals-03.txt > > Pages : 8 > > Date : 2012-07-16 > > > > Abstract: > > This document defines a set of interval values that we call "Standard > > intervals". Values of this set must be supported for transmitting > > BFD control packets and for calculating the detection time in the > > receive direction when the value is equal or larger than the fastest, > > i.e. lowest, interval a particular BFD implementation supports. > > > > This solves the problem of finding an interval value that both BFD > > speakers can support while allowing a simplified implementation as > > seen for hardware-based BFD. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-akiya-bfd-intervals > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 > > > > A diff from previous version is available at: > > http://tools.ietf.org/rfcdiff?url2=draft-akiya-bfd-intervals-03 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > -- > Marc Binderberger > > --bcaec550b36cfc2ef504c59bcc4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Marc, et al.,
I think I'd refer to the set of timer values define= d in the draft-akiya-bfd-intervals as 'Minimally Required Set" rat= her than as "Standard".
Second, 3.3 ms interval included in th= e set for the benefit of MPLS-TP. I'd note that OAM for packet transpor= t networks would likely to use from set of intervals defined in IEEE 802.1a= g/Y.1731, i.e. [3.3 ms, 10 ms, 100 ms, 1 sec, 10 sec, 1 min, 10 min]. To ma= ke two sets more compatible, I propose to include 100 ms interval into the = Minimally Required Set that proposed in the draft.

Regards,
Greg

On Mon, Jul 16, 2012= at 3:31 AM, Marc Binderberger <marc@sniff.de> wrote:
Hello BFD experts,

Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, mainl= y fixing some typos and adding one clarification.

We received (unicast) several feedbacks, in general positive. What still ma= y require a closer look is:

(i) =A0the set of Standard Interval values

(ii) the Poll/Final sequence example in Appendix B


Thanks & Regards,
Marc



Begin forwarded message:

> From: internet-drafts@ietf= .org
> Date: July 16, 2012 12:25:32 GMT+02:00
> To: i-d-announce@ietf.org=
> Subject: I-D Action: draft-akiya-bfd-intervals-03.txt
> Reply-To: internet-drafts@= ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Standardized interval support = in BFD
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Nobo Akiya
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Marc Binderberger > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-akiya-bfd-intervals-03.txt=
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-07-16
>
> Abstract:
> =A0 This document defines a set of interval values that we call "= Standard
> =A0 intervals". =A0Values of this set must be supported for trans= mitting
> =A0 BFD control packets and for calculating the detection time in the<= br> > =A0 receive direction when the value is equal or larger than the faste= st,
> =A0 i.e. lowest, interval a particular BFD implementation supports. >
> =A0 This solves the problem of finding an interval value that both BFD=
> =A0 speakers can support while allowing a simplified implementation as=
> =A0 seen for hardware-based BFD.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akiya-bfd-interva= ls
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-akiya-bfd-intervals-03=
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-akiya-= bfd-intervals-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <= marc@sniff.de>


--bcaec550b36cfc2ef504c59bcc4e-- From jhaas@slice.pfrc.org Wed Jul 25 10:50:21 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 3C31421F86D5 for ; Wed, 25 Jul 2012 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=0.127, 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 R872xcFlglyj for ; Wed, 25 Jul 2012 10:50:20 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BEBFB21F8629 for ; Wed, 25 Jul 2012 10:50:20 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CBDB5C95B; Wed, 25 Jul 2012 13:50:17 -0400 (EDT) Date: Wed, 25 Jul 2012 13:50:17 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: IETF 84 meeting - call for presentations Message-ID: <20120725175017.GB8831@pfrc> References: <20120709154731.GB22984@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120709154731.GB22984@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, 25 Jul 2012 17:50:21 -0000 I'll be uploading a formal agenda momentarily, but at this point our agenda is: - Discuss BFD over LAGs. - MIB breakout session. Our agenda is thin enough that we probably should cancel the meeting, but experience from our last session showed that list feedback on the BFD over LAG draft didn't reflect room consensus terribly well. I'd like to give us the opportunity to discuss this in detail. The MIB breakout session will not be presentation driven. People with interest in the BFD MIBs will be invited to get together in a tight group and do a review of the MIB objects, operational model, etc. Think of it as a pre-MIB Doctor review. Given the nature of the MIB breakout, our formal agenda is expected to wrap up very quickly. Since our conflict list gave us a timeslot of 1.5 hours, we still have openings for relevant agenda items. Please send requests to the list. -- Jeff On Mon, Jul 09, 2012 at 11:47:31AM -0400, Jeffrey Haas wrote: > Working Group, > > We shall be meeting at the upcoming IETF 84 session in Vancouver, Canada. > This is a call for presentations for the working group session. > [...] From wim.henderickx@alcatel-lucent.com Thu Jul 26 22:24:02 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 C462F11E80B7 for ; Thu, 26 Jul 2012 22:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.639 X-Spam-Level: X-Spam-Status: No, score=-8.639 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, HELO_EQ_FR=0.35, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_HI=-8] 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 lCow9jKtn+Cu for ; Thu, 26 Jul 2012 22:24:02 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCC321F8422 for ; Thu, 26 Jul 2012 22:24:01 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6R5O0KE013371 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jul 2012 07:24:00 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 27 Jul 2012 07:24:00 +0200 From: "Henderickx, Wim (Wim)" To: "draft-mmm-bfd-on-lags@tools.ietf.org" Date: Fri, 27 Jul 2012 07:23:59 +0200 Subject: draft-mmm-bfd-on-lags Thread-Topic: draft-mmm-bfd-on-lags Thread-Index: Ac1ruAbo99OPNC7LTAeJChbI2TaZKQ== Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6702E16333FA@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 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, 27 Jul 2012 05:24:02 -0000 Hi, I have a question on section 2.3 with respect to the use of the destination= MAC in the micro BFD section. The current draft says that: When sending BFD packets for the micro BFD ses= sion in the Up state, the MAC address from the received BFD packets for the session MUST be used. Can this be more relaxed in the sense that micro-BFD session could keep usi= ng the dedicated MAC address during the complete lifetime of the session? This might make implementations easier. Cheers, Wim From venkat.mahalingams@gmail.com Fri Jul 27 16:00:18 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 2EA9111E80F4; Fri, 27 Jul 2012 16:00:18 -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 Wm7eNSAN0PZ1; Fri, 27 Jul 2012 16:00:17 -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 71F1D11E80C4; Fri, 27 Jul 2012 16:00:17 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3373996vbb.31 for ; Fri, 27 Jul 2012 16:00:11 -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=GMFKqHM7A96SPN2qojbUoEMc3DGk9IvY8wi8kHuCI5U=; b=cmFikg5ZG39omsk1Dg/QymmiunA+m6S8nmAHymlA6xb/+sJTOxJydGxTvZ0kVk2JR7 u3io771V+2xM//q3dC0RmVCjmETOFuJqEtFag7HhQN02c7I+Dm5BUztLVkN0apOPwPt7 /qCkYuvUz0Fejx2qCOYREnM/OVOi68PaPFjkzAd8jsGnDYiQKBHvubkiO6sxU2W2Cd5B l5En9HwUOtCRwQf0W2wzPN9iuIrNY2WUJjd22TDaSiwA9UDT1wFCs+c5tY2xhZMTjp+0 ZKOF/3Dc2jLmFnJZRFvfLeulzxDb6mOn3tus9QGmQhenM52fA+vOyNaIAIkV4vBfWhr3 VECA== MIME-Version: 1.0 Received: by 10.52.93.202 with SMTP id cw10mr3723463vdb.1.1343430011065; Fri, 27 Jul 2012 16:00:11 -0700 (PDT) Received: by 10.220.193.6 with HTTP; Fri, 27 Jul 2012 16:00:10 -0700 (PDT) In-Reply-To: <79855A9D77725540834FF21F892FF7988835ECAD@ENFICSMBX1.datcon.co.uk> References: <79855A9D77725540834FF21F892FF7988835ECAD@ENFICSMBX1.datcon.co.uk> Date: Fri, 27 Jul 2012 16:00:10 -0700 Message-ID: Subject: Re: Comments on draft-ietf-bfd-mpls-mib-00 From: Venkatesan Mahalingam To: John Salloway Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 30 Jul 2012 09:12:17 -0700 Cc: "draft-ietf-bfd-mpls-mib@tools.ietf.org" , "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: Fri, 27 Jul 2012 23:00:18 -0000 John, Thanks for your comments. Please find below the response inlined with the tag [VM]. Regards, Venkat. On Fri, Jul 27, 2012 at 10:37 AM, John Salloway wrote: > Hi, > > > > I have a couple of comments on draft-ietf-bfd-mpls-mib-00. > > > > 1. The bfdMplsSessTable contains a pointer to the service associated > with this BFD session. I would have thought it would be useful to have a > link in the other direction (for example a row pointer or session index in > the mplsTunnelEntry or mplsTunnelExtEntry to identify the BFD session). I > can see no simple way to find the BFD Session that is monitoring the MPLS > Tunnel. > [VM] Agree. I'll discuss with other authors and conclude on this. > > 2. The service pointer (bfdMplsSessMapPointer) points to a different > table depending for MPLS-TE tunnels and MPLS-TP tunnels. For MPLS-TE > Tunnels, this points to an entry in the mplsTunnelTable. For MPLS-TP > tunnels, it points to an entry in the mplsOamIdMeTable. Would it not be > simpler for it to point to an mplsTunnelEntry in both cases? > [VM] For MPLS-TP case also, we can point to mplsTunnelTable, there is no restriction enforced in this MIB but in order to satisfy the OAM requirements of MPLS-TP, it is expected to point to mplsOamIdMeTable. > > Have I missed something? > > > > Thanks > > > > John Salloway From jhaas@slice.pfrc.org Mon Jul 30 10:47:39 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 BB25221F8685 for ; Mon, 30 Jul 2012 10:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=0.120, 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 f6EeFIDWBT0Y for ; Mon, 30 Jul 2012 10:47:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D4DE921F8663 for ; Mon, 30 Jul 2012 10:47:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5DABED114; Mon, 30 Jul 2012 13:47:38 -0400 (EDT) Date: Mon, 30 Jul 2012 13:47:38 -0400 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: [nomcom-chair@ietf.org: NomCom 2012-2013: Second Call for Volunteers] Message-ID: <20120730174738.GB24031@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: Mon, 30 Jul 2012 17:47:39 -0000 I'd like to encourage you to consider volunteering for the NomCom if you're eligible. -- Jeff ----- Forwarded message from NomCom Chair ----- Date: Tue, 24 Jul 2012 13:06:04 -0700 From: NomCom Chair To: IETF Announcement List Subject: NomCom 2012-2013: Second Call for Volunteers The NomCom 2012-2013 Call for Volunteers has now passed its halfway point. Therefore, if you are considering volunteering to participate in the 2012-2013 NomCom, please do so soon. General information on this year's NomCom (including a list of positions to be filled) can be found at: https://www.ietf.org/nomcom/2012/ The success of the NomCom process depends on randomly selecting a committee that is a representative sample of the our community. We endeavor to have a NomCom reflecting the diversity of experience and viewpoints that is our community's greatest strength. However, to achieve this goal we must have the largest possible pool of volunteers that from throughout the IETF community. I am pleased to report that we have had a strong initial response to the First Call for Volunteers, with 74 qualified individuals agreeing to volunteer their time. I greatly appreciate the generosity and commitment to our community exhibited by all of these individuals. However, the pool of volunteers is not yet as diverse as it should be to reflect the breadth of our community with regards to nationality, gender and organizational affiliation. Therefore, I would especially encourage to volunteer those individuals whose participation would increase the diversity of our volunteer pool. If you have volunteered before 12:00 noon UTC on July 24, 2012 and you have not received a confirmation email from me, then an error has occurred and I would request that you resend your email. Details on how to volunteer can be found at the end of this message. To summarize, please volunteer by sending me an email containing your name, affiliation, and the email address you use to register for IETF meetings. The 74 qualified individuals who have so far volunteered are listed below. I apologize for any errors in this list, please notify me of any errors as soon as possible. Sam Aldrin, Huawei Ignas Bagdonas, Cisco Lou Berger, LabN Consulting Randy Bush, IIJ Dennis Cai, Cisco Daniele Ceccarelli, Ericsson Gang Chen, China Mobile Andras Csaszar, Ericsson Hui Deng, China Mobile Keith Drage, Alcatel-Lucent John Drake, Juniper Donald Eastlake, Huawei Charles Eckel, Cisco Mehmet Ersue, Nokia Siemens Networks Miguel Garcia, Ericsson Eric Gray, Ericsson Wassim Haddad, Ericsson Stephen Hanna, Juniper Sam Hartman, Painless Security Jia He, Huawei Giles Heron, Cisco Paul Hoffman, VPN Consortium Christer Holmberg, Ericsson Fangwei Hu, ZTE Andrew Hutton, Siemens Enterprise Communications Cullen Jennings, Cisco Yuanlong Jiang, Huawei Sheng Jiang, Huawei Lizhong Jin, ZTE Stephen Kent, BBN Ari Keranen, Ericsson Ning Kong, CNNIC Jouni Korhonen, Nokia Siemens Networks Mirja Kuehlewind, University of Stuttgart Eliot Lear, Cisco Hongyu Li, Huawei Guoman Liu, ZTE Wenhu Lu, Ericsson Yuxia Ma, ZTE Andrew Malis, Verizon Terry Manderson, ICANN Scott Mansfield, Ericsson Luca Martini, Cisco David Meyer, Cisco Monique Morrow, Cisco Thomas Nadeau, Juniper Karen O'Donoghue, Internet Society Borje Ohlman, Ericsson Keyur Patel, Cisco Teemu Savolainen, Nokia Benson Schliesser, Juniper John Scudder, Juniper Karen Seo, BBN Arturo Servin, LACNIC Shuo (Sean) Shen, CNNIC David Sini, Ericsson Haibin Song, Huawei Tom Taylor, PT Taylor Consulting Pascal Thubert, Cisco Mark Townsley, Cisco Tina Tsou, Huawei Bill VerSteeg, Cisco Thomas Walsh, Juniper Yinxing Wei, ZTE Stephan Wenger, Vidyo Magnus Westerlund, Ericsson Steven White, Alcatel-Lucent Qin (Bill) Wu, Huawei Leaf Yeh, Huawei Lixia Zhang, UCLA Zhaohui (Jeff) Zhang, Juniper Yi Zhao, Huawei Qian (Cathy) Zhou, Huawei Ning Zong, Huawei To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple days. Thank you, Matthew Lepinski nomcom-chair@ietf.org (or mlepinski.ietf@gmail.com) ----- End forwarded message ----- From pabloisnot@gmail.com Tue Jul 31 14:28:31 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 9C37921F887F for ; Tue, 31 Jul 2012 14:28:31 -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 Ju5NUuKzlF-c for ; Tue, 31 Jul 2012 14:28:30 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF021F886B for ; Tue, 31 Jul 2012 14:28:29 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so3734707wib.1 for ; Tue, 31 Jul 2012 14:28: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:date:message-id:subject:from:to :cc:content-type; bh=QJNyMw2YuDufjbDjH8N2LwF6oeYkAnQxtUHavxWlqn0=; b=ql6O92Pqft49M5CjVptjPi2OLJGbbirvn29AFAO3uky/CJzX0Ufbzdr8vCxqVo8HrC /eEmH27mdhpD21ijPW1L9jtp0ShMCKmn2nIW3v64Z0SBqwD14yf8G9laXxq56OzeP/Pn zSH1Uig+eaZhiRuY9P+mblUlYAWEgm/+TN5p86uzSdKeTQEk/4olK2zCG6NGzU8EPgqA 1jN8soc3SKILgIJvlarqeQA7Ds2TUYjrao/bnEa/FQZCCsWwdKLQUBY02tKaBgpEOm2M 9Zq9/wVM6bRG6oHGEZfsmpp0ojeqtJ/KEuFBzxYtUTIx3SiMSZWnt4ubNvMpXx+GW6Oc d6lg== MIME-Version: 1.0 Received: by 10.180.98.138 with SMTP id ei10mr10800126wib.1.1343770109039; Tue, 31 Jul 2012 14:28:29 -0700 (PDT) Received: by 10.227.197.206 with HTTP; Tue, 31 Jul 2012 14:28:28 -0700 (PDT) In-Reply-To: References: <20120716102532.2738.60203.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 17:28:28 -0400 Message-ID: Subject: Re: I-D Action: draft-akiya-bfd-intervals-03.txt From: Pablo Frank To: Greg Mirsky Content-Type: multipart/alternative; boundary=f46d044267fe0255e604c626dcf6 Cc: rtg-bfd@ietf.org, draft-akiya-bfd-intervals@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: Tue, 31 Jul 2012 21:28:31 -0000 --f46d044267fe0255e604c626dcf6 Content-Type: text/plain; charset=ISO-8859-1 I'd like to echo Greg's suggestion that we should align the minimum set of required rates against 802.1ag/Y.1731. However, I'd like to make the argument that you should consider *removing* some of the rates suggested in the draft. In my mind, the main value in this draft specifying a minimum set of supported intervals is really to set minimum standards for hardware implementations. Software implementations of BFD will typically have the ability to be very flexible above a certain point. In other words, a software implementation that can minimally support 100ms intervals can likely support nearly any rate that is slower than 100ms. OTOH, hardware implementations tend to be fairly restricted in the number of high-speed rates that they can support. I've seen merchant silicon implementations that can really only do 3 or 4 "fast" rates (i.e. <1pps). Specifying too many rates will likely increase the cost of these solutions and we should only do this if there is a strong use-case to justify pushing these requirements on silicon vendors. In terms of the suggested rates, both 3.3ms and 10ms are rates suggested for CC/CV for MPLS-TP in RFC 6371 to support protection-switching so should be included in the minimum set. The draft suggests 20ms (or 15ms) as another rate that can support 50ms switchovers but this is impractical since worst-case detection time for faults using 20ms CC/CV is 2.5 x 20ms = 50ms, which leaves you essentially no time to perform the actual switchover. The draft also suggests 50ms as a rate that some software implementations can achieve. IMHO, this is irrelevant. There are probably software implementations that could also achieve 25ms or even 10ms. That doesn't seem to be a good reason to add it to the list. AFAIK, there is no application that really benefits from 50ms CC/CV that would not be adequately served by 100ms. 50ms CC/CV certainly won't achieve 50ms protection switching times, even with a defect multiplier of 1. As Greg suggests, we should certainly add 100ms to the list. RFC 6371 also lists 100ms as a rate that is useful to support performance-monitoring applications in MPLS-TP networks. It's worth noting that hardware that does periodic LM/DM will often share common timer infrastructure with CC/CV so it's good to align on these rates. 1s is also called out by RFC 6371. The draft also suggests 300ms to support VOIP applications that require <1s detection time. But this makes the same erroneous assumption as the 20ms rate. With a 300ms CC/CV interval and a defect multiplier of 3, defect-entry can occur as late as 3.5 x 300ms = 1050ms which violates the 1s requirement. I would suggest that the 100ms interval can probably serve this application just fine. But it would be good to get the opinions of any VOIP experts on the list. In summary, I would suggest 3.3ms, 10ms, 100ms, and 1s as the minimal set. I would delete 20ms, 50ms, and 300ms. regards, Pablo On Tue, Jul 24, 2012 at 7:34 PM, Greg Mirsky wrote: > Hi Marc, et al., > I think I'd refer to the set of timer values defined in the > draft-akiya-bfd-intervals as 'Minimally Required Set" rather than as > "Standard". > Second, 3.3 ms interval included in the set for the benefit of MPLS-TP. > I'd note that OAM for packet transport networks would likely to use from > set of intervals defined in IEEE 802.1ag/Y.1731, i.e. [3.3 ms, 10 ms, 100 > ms, 1 sec, 10 sec, 1 min, 10 min]. To make two sets more compatible, I > propose to include 100 ms interval into the Minimally Required Set that > proposed in the draft. > > Regards, > Greg > > > On Mon, Jul 16, 2012 at 3:31 AM, Marc Binderberger wrote: > >> Hello BFD experts, >> >> Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, >> mainly fixing some typos and adding one clarification. >> >> We received (unicast) several feedbacks, in general positive. What still >> may require a closer look is: >> >> (i) the set of Standard Interval values >> >> (ii) the Poll/Final sequence example in Appendix B >> >> >> Thanks & Regards, >> Marc >> >> >> >> Begin forwarded message: >> >> > From: internet-drafts@ietf.org >> > Date: July 16, 2012 12:25:32 GMT+02:00 >> > To: i-d-announce@ietf.org >> > Subject: I-D Action: draft-akiya-bfd-intervals-03.txt >> > Reply-To: internet-drafts@ietf.org >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > >> > >> > Title : Standardized interval support in BFD >> > Author(s) : Nobo Akiya >> > Marc Binderberger >> > Filename : draft-akiya-bfd-intervals-03.txt >> > Pages : 8 >> > Date : 2012-07-16 >> > >> > Abstract: >> > This document defines a set of interval values that we call "Standard >> > intervals". Values of this set must be supported for transmitting >> > BFD control packets and for calculating the detection time in the >> > receive direction when the value is equal or larger than the fastest, >> > i.e. lowest, interval a particular BFD implementation supports. >> > >> > This solves the problem of finding an interval value that both BFD >> > speakers can support while allowing a simplified implementation as >> > seen for hardware-based BFD. >> > >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-akiya-bfd-intervals >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 >> > >> > A diff from previous version is available at: >> > http://tools.ietf.org/rfcdiff?url2=draft-akiya-bfd-intervals-03 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www.ietf.org/mailman/listinfo/i-d-announce >> > Internet-Draft directories: http://www.ietf.org/shadow.html >> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> >> -- >> Marc Binderberger >> >> > --f46d044267fe0255e604c626dcf6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to echo Greg's suggestion that we should align the minimum= set of required rates against 802.1ag/Y.1731. =A0However, I'd like to = make the argument that you should consider *removing* some of the rates sug= gested in the draft. =A0In my mind, the main value in this draft specifying= a minimum set of supported intervals is really to set minimum standards fo= r hardware implementations. =A0Software implementations of BFD will typical= ly have the ability to be very flexible above a certain point. =A0In other = words, a software implementation that can minimally support 100ms intervals= can likely support nearly any rate that is slower than 100ms. =A0OTOH, har= dware implementations tend to be fairly restricted in the number of high-sp= eed rates that they can support. =A0I've seen merchant silicon implemen= tations that can really only do 3 or 4 "fast" rates (i.e. <1pp= s). =A0Specifying too many rates will likely increase the cost of these sol= utions and we should only do this if there is a strong use-case to justify = pushing these requirements on silicon vendors.

In terms of the suggested rates, both 3.3ms and 10ms are rat= es suggested for CC/CV for MPLS-TP in=A0RFC 6371=A0to support protection-switching so= should be included in the minimum set. =A0The draft suggests 20ms (or 15ms= ) as another rate that can support 50ms switchovers but this is impractical= since worst-case detection time for faults using 20ms CC/CV is 2.5 x 20ms = =3D 50ms, which leaves you essentially no time to perform the actual switch= over. =A0

The draft also suggests 50ms as a rate that some softwa= re implementations can achieve. =A0IMHO, this is irrelevant. =A0There are p= robably software implementations that could also achieve 25ms or even 10ms.= =A0That doesn't seem to be a good reason to add it to the list. =A0AFA= IK, there is no application that really benefits from 50ms CC/CV that would= not be adequately served by 100ms. =A050ms CC/CV certainly won't achie= ve 50ms protection switching times, even with a defect multiplier of 1.

As Greg suggests, we should certainly add 100ms to the = list. =A0RFC 6371 also lists 100ms as a rate that is useful to support perf= ormance-monitoring applications in MPLS-TP networks. =A0It's worth noti= ng that hardware that does periodic LM/DM will often share common timer inf= rastructure with CC/CV so it's good to align on these rates. =A01s is a= lso called out by RFC 6371.

The draft also suggests 300ms to support VOIP applicati= ons that require <1s detection time. =A0But this makes the same erroneou= s assumption as the 20ms rate. =A0With a 300ms CC/CV interval and a defect = multiplier of 3, defect-entry can occur as late as 3.5 x 300ms =3D 1050ms w= hich violates the 1s requirement. =A0I would suggest that the 100ms interva= l can probably serve this application just fine. =A0But it would be good to= get the opinions of any VOIP experts on the list.

In summary, I would suggest 3.3ms, 10ms, 100ms, and 1s = as the minimal set. =A0I would delete 20ms, 50ms, and 300ms.

=
regards,
Pablo

On Tue, Jul 24, 2012 at 7:34 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Marc, et al.,
I think I'd refer to the set of timer values define= d in the draft-akiya-bfd-intervals as 'Minimally Required Set" rat= her than as "Standard".
Second, 3.3 ms interval included in th= e set for the benefit of MPLS-TP. I'd note that OAM for packet transpor= t networks would likely to use from set of intervals defined in IEEE 802.1a= g/Y.1731, i.e. [3.3 ms, 10 ms, 100 ms, 1 sec, 10 sec, 1 min, 10 min]. To ma= ke two sets more compatible, I propose to include 100 ms interval into the = Minimally Required Set that proposed in the draft.

Regards,
Greg


On Mon, Jul 16, 2012 at 3:31 AM, Marc Binderberger <marc@s= niff.de> wrote:
Hello BFD experts,

Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, mainl= y fixing some typos and adding one clarification.

We received (unicast) several feedbacks, in general positive. What still ma= y require a closer look is:

(i) =A0the set of Standard Interval values

(ii) the Poll/Final sequence example in Appendix B


Thanks & Regards,
Marc



Begin forwarded message:

> From: in= ternet-drafts@ietf.org
> Date: July 16, 2012 12:25:32 GMT+02:00
> To: i-d-ann= ounce@ietf.org
> Subject: I-D Action: draft-akiya-bfd-intervals-03.txt
> Reply-To: internet-drafts@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Standardized interval support = in BFD
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Nobo Akiya
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Marc Binderberger > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-akiya-bfd-intervals-03.txt=
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-07-16
>
> Abstract:
> =A0 This document defines a set of interval values that we call "= Standard
> =A0 intervals". =A0Values of this set must be supported for trans= mitting
> =A0 BFD control packets and for calculating the detection time in the<= br> > =A0 receive direction when the value is equal or larger than the faste= st,
> =A0 i.e. lowest, interval a particular BFD implementation supports. >
> =A0 This solves the problem of finding an interval value that both BFD=
> =A0 speakers can support while allowing a simplified implementation as=
> =A0 seen for hardware-based BFD.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akiya-bfd-interva= ls
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-akiya-bfd-intervals-03=
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-akiya-= bfd-intervals-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

--
Marc Binderberger =A0 =A0 =A0 =A0 =A0 <marc@sniff.de>



--f46d044267fe0255e604c626dcf6-- From marc@sniff.de Tue Jul 31 15:57:46 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 02D1711E8153 for ; Tue, 31 Jul 2012 15:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=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 1++870hoq1MA for ; Tue, 31 Jul 2012 15:57:44 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A038111E8151 for ; Tue, 31 Jul 2012 15:57:43 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 607D42AA0F; Tue, 31 Jul 2012 22:57:39 +0000 (GMT) Subject: Re: I-D Action: draft-akiya-bfd-intervals-03.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-396037321 From: Marc Binderberger In-Reply-To: Date: Wed, 1 Aug 2012 00:57:37 +0200 Message-Id: <1547F1A4-D799-4BE5-A762-7F3EED769BBA@sniff.de> References: <20120716102532.2738.60203.idtracker@ietfa.amsl.com> To: Greg Mirsky , Pablo Frank X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd@ietf.org, draft-akiya-bfd-intervals@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: Tue, 31 Jul 2012 22:57:46 -0000 --Apple-Mail-2-396037321 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Greg and Pablo, sorry for the late reply, simply busy. And thanks for the feedback! I'm perfectly fine adding the 100msec. For removing the 300msec, true = that 3 x 300msec or 9 x 100msec should cover the same scenarios. I hope = that we get some more feedback from vendors (not just routers) if we can = drop 300msec. I do not agree with the sparse list with the large jump from 10msec to = 100msec, even if IEEE does. Reality is not black/white and being close = to 50-60msec detection time is still better than being off like = 200-300msec. Thus the 20msec. It was actually this gap that motivated us = writing this draft :-) > The draft also suggests 50ms as a rate that some software = implementations can achieve. IMHO, this is irrelevant. With 20msec and 100msec available one may replace 50msec in terms of = dection time. On the other hand 50msec is a value I've seen quite often, = i.e. it's not irrelevant. This draft is about interoperability in the = sense that existing/older software-based implementations can peer with = silicon-based BFD while largely maintaining the existing detection = times. But again, the discussion just started. > I've seen merchant silicon implementations that can really only do 3 = or 4 "fast" rates fair point, on the other hand BFD solutions and thus "typical" timer = values are out in the world and the silicon vendors are not reinventing = BFD. Plus you can use silicon for the really fast BFD and use cheaper = software for the not-so-fast timers. But to find the balance is what this discussion is for :-)=20 Regarding the additional ".5" in your detection time calculation, while = I guess I understand this from a hardware implementation point of view I = somewhat disagree. =46rom RFC5880: 6.8.4. Calculating the Detection Time [...] In Asynchronous mode, the Detection Time calculated in the local system is equal to the value of Detect Mult received from the remote = =20 system, multiplied by the agreed transmit interval of the remote system (the greater of bfd.RequiredMinRxInterval and the last received Desired Min TX Interval). So M * I (M: remote Multiplier, I: remote agreed transmit interval) = should be your upper limit until when you have detected that the link or = TP tunnel is interrupted. (M-1) * I would be the lower boundary. For the larger values that Greg mentioned (10 sec, 1 min, 10 min) I = still have to give this a thought. Larger timer (and multiplier) values = are one way to achieve "graceful restart" for BFD and I've heard about = interop problems with it as well, so maybe worthwhile to cover in this = draft as well. Anyway, thanks again for the feedback and opinion! Regards, Marc On 2012-07-31, at 23:28 , Pablo Frank wrote: > I'd like to echo Greg's suggestion that we should align the minimum = set of required rates against 802.1ag/Y.1731. However, I'd like to make = the argument that you should consider *removing* some of the rates = suggested in the draft. In my mind, the main value in this draft = specifying a minimum set of supported intervals is really to set minimum = standards for hardware implementations. Software implementations of BFD = will typically have the ability to be very flexible above a certain = point. In other words, a software implementation that can minimally = support 100ms intervals can likely support nearly any rate that is = slower than 100ms. OTOH, hardware implementations tend to be fairly = restricted in the number of high-speed rates that they can support. = I've seen merchant silicon implementations that can really only do 3 or = 4 "fast" rates (i.e. <1pps). Specifying too many rates will likely = increase the cost of these solutions and we should only do this if there = is a strong use-case to justify pushing these requirements on silicon = vendors. >=20 > In terms of the suggested rates, both 3.3ms and 10ms are rates = suggested for CC/CV for MPLS-TP in RFC 6371 to support = protection-switching so should be included in the minimum set. The = draft suggests 20ms (or 15ms) as another rate that can support 50ms = switchovers but this is impractical since worst-case detection time for = faults using 20ms CC/CV is 2.5 x 20ms =3D 50ms, which leaves you = essentially no time to perform the actual switchover. =20 >=20 > The draft also suggests 50ms as a rate that some software = implementations can achieve. IMHO, this is irrelevant. There are = probably software implementations that could also achieve 25ms or even = 10ms. That doesn't seem to be a good reason to add it to the list. = AFAIK, there is no application that really benefits from 50ms CC/CV that = would not be adequately served by 100ms. 50ms CC/CV certainly won't = achieve 50ms protection switching times, even with a defect multiplier = of 1. >=20 > As Greg suggests, we should certainly add 100ms to the list. RFC 6371 = also lists 100ms as a rate that is useful to support = performance-monitoring applications in MPLS-TP networks. It's worth = noting that hardware that does periodic LM/DM will often share common = timer infrastructure with CC/CV so it's good to align on these rates. = 1s is also called out by RFC 6371. >=20 > The draft also suggests 300ms to support VOIP applications that = require <1s detection time. But this makes the same erroneous = assumption as the 20ms rate. With a 300ms CC/CV interval and a defect = multiplier of 3, defect-entry can occur as late as 3.5 x 300ms =3D = 1050ms which violates the 1s requirement. I would suggest that the = 100ms interval can probably serve this application just fine. But it = would be good to get the opinions of any VOIP experts on the list. >=20 > In summary, I would suggest 3.3ms, 10ms, 100ms, and 1s as the minimal = set. I would delete 20ms, 50ms, and 300ms. >=20 > regards, > Pablo >=20 > On Tue, Jul 24, 2012 at 7:34 PM, Greg Mirsky = wrote: > Hi Marc, et al., > I think I'd refer to the set of timer values defined in the = draft-akiya-bfd-intervals as 'Minimally Required Set" rather than as = "Standard". > Second, 3.3 ms interval included in the set for the benefit of = MPLS-TP. I'd note that OAM for packet transport networks would likely to = use from set of intervals defined in IEEE 802.1ag/Y.1731, i.e. [3.3 ms, = 10 ms, 100 ms, 1 sec, 10 sec, 1 min, 10 min]. To make two sets more = compatible, I propose to include 100 ms interval into the Minimally = Required Set that proposed in the draft. >=20 > Regards, > Greg >=20 >=20 > On Mon, Jul 16, 2012 at 3:31 AM, Marc Binderberger = wrote: > Hello BFD experts, >=20 > Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, = mainly fixing some typos and adding one clarification. >=20 > We received (unicast) several feedbacks, in general positive. What = still may require a closer look is: >=20 > (i) the set of Standard Interval values >=20 > (ii) the Poll/Final sequence example in Appendix B >=20 >=20 > Thanks & Regards, > Marc >=20 >=20 >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Date: July 16, 2012 12:25:32 GMT+02:00 > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-akiya-bfd-intervals-03.txt > > Reply-To: internet-drafts@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > > > > Title : Standardized interval support in BFD > > Author(s) : Nobo Akiya > > Marc Binderberger > > Filename : draft-akiya-bfd-intervals-03.txt > > Pages : 8 > > Date : 2012-07-16 > > > > Abstract: > > This document defines a set of interval values that we call = "Standard > > intervals". Values of this set must be supported for transmitting > > BFD control packets and for calculating the detection time in the > > receive direction when the value is equal or larger than the = fastest, > > i.e. lowest, interval a particular BFD implementation supports. > > > > This solves the problem of finding an interval value that both BFD > > speakers can support while allowing a simplified implementation as > > seen for hardware-based BFD. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-akiya-bfd-intervals > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-akiya-bfd-intervals-03 > > > > A diff from previous version is available at: > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-intervals-03 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >=20 > -- > Marc Binderberger >=20 >=20 >=20 -- Marc Binderberger --Apple-Mail-2-396037321 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello Greg and = Pablo,

sorry for the late reply, simply busy. And thanks for = the feedback!


I'm perfectly fine adding the 100msec. For removing the = 300msec, true that 3 x 300msec or 9 x 100msec should cover the same = scenarios. I hope that we get some more feedback from vendors (not just = routers) if we can drop 300msec.

I do not agree with the = sparse list with the large jump from 10msec to 100msec, even if IEEE = does. Reality is not black/white and being close to 50-60msec detection = time is still better than being off like 200-300msec. Thus the 20msec. = It was actually this gap that motivated us writing this draft = :-)


The draft also suggests = 50ms as a rate that some software implementations can achieve. =  IMHO, this is = irrelevant.

With 20msec and 100msec = available one may replace 50msec in terms of dection time. On the other = hand 50msec is a value I've seen quite often, i.e. it's not irrelevant. = This draft is about interoperability in the sense that existing/older = software-based implementations can peer with silicon-based BFD while = largely maintaining the existing detection times. But again, = the discussion just started.


I've = seen merchant silicon implementations that can really only do 3 or 4 = "fast" rates

fair point, on the other hand = BFD solutions and thus "typical" timer values are out in the world and = the silicon vendors are not reinventing BFD. Plus you can use silicon = for the really fast BFD and use cheaper software for the not-so-fast = timers.

But to find the balance is what this discussion is for = :-) 


Regarding the additional ".5" in your detection time = calculation, while I guess I understand this from a hardware = implementation point of view I somewhat disagree. =46rom = RFC5880:

6.8.4.  Calculating the Detection = Time
= [...]
   In Asynchronous mode, the Detection = Time calculated in the local
   system is equal to = the value of Detect Mult received from the remote   =   
   system, multiplied by the agreed = transmit interval of the remote
   system (the = greater of bfd.RequiredMinRxInterval and the last
  =  received Desired Min TX Interval).


So  M * I (M: remote = Multiplier, I: remote agreed transmit interval) should be your upper = limit until when you have detected that the link or TP tunnel is = interrupted. (M-1) * I would be the lower = boundary.


For the larger values that Greg mentioned (10 sec, 1 = min, 10 min)  I still have to give this a thought. = Larger timer (and multiplier) values are one way to achieve "graceful = restart" for BFD and I've heard about interop problems with it as well, = so maybe worthwhile to cover in this draft as = well.

Anyway, thanks again for the feedback = and opinion!

Regards, Marc



On 2012-07-31, at 23:28 = , Pablo Frank wrote:

I'd like to echo Greg's suggestion that we should = align the minimum set of required rates against 802.1ag/Y.1731. =  However, I'd like to make the argument that you should consider = *removing* some of the rates suggested in the draft.  In my mind, = the main value in this draft specifying a minimum set of supported = intervals is really to set minimum standards for hardware = implementations.  Software implementations of BFD will typically = have the ability to be very flexible above a certain point.  In = other words, a software implementation that can minimally support 100ms = intervals can likely support nearly any rate that is slower than 100ms. =  OTOH, hardware implementations tend to be fairly restricted in the = number of high-speed rates that they can support.  I've seen = merchant silicon implementations that can really only do 3 or 4 "fast" = rates (i.e. <1pps).  Specifying too many rates will likely = increase the cost of these solutions and we should only do this if there = is a strong use-case to justify pushing these requirements on silicon = vendors.

In terms of the suggested rates, both 3.3ms and 10ms are = rates suggested for CC/CV for MPLS-TP in RFC = 6371 to support protection-switching so should be included in = the minimum set.  The draft suggests 20ms (or 15ms) as another rate = that can support 50ms switchovers but this is impractical since = worst-case detection time for faults using 20ms CC/CV is 2.5 x 20ms =3D = 50ms, which leaves you essentially no time to perform the actual = switchover.  

The draft also suggests 50ms as a rate that some = software implementations can achieve.  IMHO, this is irrelevant. =  There are probably software implementations that could also = achieve 25ms or even 10ms.  That doesn't seem to be a good reason = to add it to the list.  AFAIK, there is no application that really = benefits from 50ms CC/CV that would not be adequately served by 100ms. =  50ms CC/CV certainly won't achieve 50ms protection switching = times, even with a defect multiplier of 1.

As Greg suggests, we should certainly add 100ms to = the list.  RFC 6371 also lists 100ms as a rate that is useful to = support performance-monitoring applications in MPLS-TP networks. =  It's worth noting that hardware that does periodic LM/DM will = often share common timer infrastructure with CC/CV so it's good to align = on these rates.  1s is also called out by RFC 6371.

The draft also suggests 300ms to support VOIP = applications that require <1s detection time.  But this makes = the same erroneous assumption as the 20ms rate.  With a 300ms CC/CV = interval and a defect multiplier of 3, defect-entry can occur as late as = 3.5 x 300ms =3D 1050ms which violates the 1s requirement.  I would = suggest that the 100ms interval can probably serve this application just = fine.  But it would be good to get the opinions of any VOIP experts = on the list.

In summary, I would suggest 3.3ms, 10ms, 100ms, and = 1s as the minimal set.  I would delete 20ms, 50ms, and = 300ms.

regards,
Pablo

On Tue, Jul 24, 2012 at 7:34 PM, Greg Mirsky <gregimirsky@gmail.com> = wrote:
Hi Marc, et al.,
I think I'd refer to the set of timer values defined = in the draft-akiya-bfd-intervals as 'Minimally Required Set" rather than = as "Standard".
Second, 3.3 ms interval included in the set for the = benefit of MPLS-TP. I'd note that OAM for packet transport networks = would likely to use from set of intervals defined in IEEE = 802.1ag/Y.1731, i.e. [3.3 ms, 10 ms, 100 ms, 1 sec, 10 sec, 1 min, 10 = min]. To make two sets more compatible, I propose to include 100 ms = interval into the Minimally Required Set that proposed in the draft.

Regards,
Greg


On Mon, Jul 16, 2012 at 3:31 AM, Marc Binderberger = <marc@sniff.de> wrote:
Hello BFD experts,

Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, = mainly fixing some typos and adding one clarification.

We received (unicast) several feedbacks, in general positive. What still = may require a closer look is:

(i)  the set of Standard Interval values

(ii) the Poll/Final sequence example in Appendix B


Thanks & Regards,
Marc



Begin forwarded message:

> From: internet-drafts@ietf.org
> Date: July 16, 2012 12:25:32 GMT+02:00
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-akiya-bfd-intervals-03.txt
> Reply-To: internet-drafts@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
>
>
>       Title           : = Standardized interval support in BFD
>       Author(s)       : Nobo = Akiya
>                   =        Marc Binderberger
>       Filename        : = draft-akiya-bfd-intervals-03.txt
>       Pages           : = 8
>       Date           =  : 2012-07-16
>
> Abstract:
>   This document defines a set of interval values that we call = "Standard
>   intervals".  Values of this set must be supported for = transmitting
>   BFD control packets and for calculating the detection time = in the
>   receive direction when the value is equal or larger than the = fastest,
>   i.e. lowest, interval a particular BFD implementation = supports.
>
>   This solves the problem of finding an interval value that = both BFD
>   speakers can support while allowing a simplified = implementation as
>   seen for hardware-based BFD.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akiya-bfd-interva= ls
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-akiya-bfd-intervals-03<= /a>
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-akiya-bfd-int= ervals-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

--
Marc Binderberger           <marc@sniff.de>




--
Marc Binderberger         =   <marc@sniff.de>