From jhaas@slice.pfrc.org Fri May 4 10:42:47 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95D721F85FD for ; Fri, 4 May 2012 10:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.906 X-Spam-Level: X-Spam-Status: No, score=-101.906 tagged_above=-999 required=5 tests=[AWL=0.359, 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 OvUJVzTka0a2 for ; Fri, 4 May 2012 10:42:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBE521F85FC for ; Fri, 4 May 2012 10:42:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9EBA0D02E; Fri, 4 May 2012 13:42:45 -0400 (EDT) Date: Fri, 4 May 2012 13:42:45 -0400 From: Jeffrey Haas To: Tom Sanders Subject: Re: [lsmt@ietf.org: New Liaison Statement, "Liaison response to IETF regarding Proposed IETF BFD WG work on Ethernet LAG"] Message-ID: <20120504174245.GB4110@pfrc> References: <20120325082306.GC24448@slice> 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, David Ward 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, 04 May 2012 17:42:48 -0000 Tom, On Thu, Apr 26, 2012 at 06:43:21AM +0530, Tom Sanders wrote: > Arent you guys coming out with a new version that incorporates the > following comments from IEEE? I also did not see any progress on the > updated charter. Is anything happening on that front? I have the token for a first round of addressing the IEEE comments. I've just had to ignore my IETF work for a while due to other work considerations. Expect to see a new draft hopefully mid next week. -- Jeff From jhaas@slice.pfrc.org Fri May 4 12:02: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 9B1C821F8568 for ; Fri, 4 May 2012 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.936 X-Spam-Level: X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=0.329, 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 psFwTb76qQ01 for ; Fri, 4 May 2012 12:02:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16A21F8421 for ; Fri, 4 May 2012 12:02:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id DBEB9D02F; Fri, 4 May 2012 15:02:36 -0400 (EDT) Date: Fri, 4 May 2012 15:02:36 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: Fwd: I-D Action: draft-akiya-bfd-intervals-01.txt Message-ID: <20120504190236.GD4110@pfrc> References: <20120425232912.26402.17632.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtg-bfd@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, 04 May 2012 19:02:38 -0000 Marc, On Thu, Apr 26, 2012 at 01:43:15AM +0200, Marc Binderberger wrote: > after some feedback Nobo and me updated the document. We changed the wording from "Mandatory interval support" towards "Standardized interval support". The "Mandatory" was an unfortunate word choice and caused confusion; my apology for this. > > We also added some clarifications. > > To summarize this draft is about an interoperability problem between BFD speakers when the number of supported intervals is small, as it may happen with hardware-based BFD. Such implementations are more difficult to upgrade (or even impossible), compared to software on general-purpose CPU, thus the attempt to avoid a foreseeable problem. > > > Discussions are welcome :-) A good step in the right direction. Minor comments: : 3. Well-defined, standardized intervals : : The problem can be reduced by defining interval values that must be : supported by all implementations. Then the adjustment mechanism : could find a commonly supported interval without deviating too much : from the original request. : : The proposed set of Standard interval values is: 3.3msec, 10msec, : 20msec, 50msec, 300msec and 1sec. Your first sentence, while a lower-case "must", still seems very demanding. Consider something like: "The problem can be reduced by defining a set of standardized intervals. Implementations that are capable of supporting one of the standardized intervals SHOULD do so. Implementations may then quickly converge on a commonly supported interval without deviating too much from the original request." -- Jeff (speaking as an individual contributor) From manav.bhatia@alcatel-lucent.com Fri May 4 16:55:15 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42A821F84BF for ; Fri, 4 May 2012 16:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 rJvoT-mq4YH3 for ; Fri, 4 May 2012 16:55:15 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9BA21F84B9 for ; Fri, 4 May 2012 16:55:14 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q44NtB41009805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 May 2012 18:55:13 -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 q44NtAaq001889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 5 May 2012 05:25:10 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sat, 5 May 2012 05:25:10 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Sat, 5 May 2012 05:25:22 +0530 Subject: Micro BFD sessions over tagged ports Thread-Topic: Micro BFD sessions over tagged ports Thread-Index: Ac0qUV3gRTJpMaRLTeWCnWJoVIIKAA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D05B7C845@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, 04 May 2012 23:55:15 -0000 Hi, Since micro sessions are essentially tracking the port (or link) status the= re needs clarity on what happens if the port is defined to have a dot1q (or= a qinq) encapsulation? I believe that similar to ethernet OAM packets, micro BFD packets should al= ways be sent untagged even on tagged dot1q or qinq ports. This way, once th= e micro BFD session times out, we can remove that link from all LAGs that u= se this port. We need a consensus on this and it has to get nailed down in the next versi= on of the draft for inter-op purposes. Cheers, Manav From manav.bhatia@alcatel-lucent.com Fri May 4 17:06: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 4B7F521E8012 for ; Fri, 4 May 2012 17:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 4AIJlVQwfYfj for ; Fri, 4 May 2012 17:06:49 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6FD11E8073 for ; Fri, 4 May 2012 17:06:49 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q4506jaj011621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 May 2012 19:06:47 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4506irm002082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 5 May 2012 05:36:45 +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, 5 May 2012 05:36:44 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Sat, 5 May 2012 05:36:59 +0530 Subject: IANA actions and WG document Thread-Topic: IANA actions and WG document Thread-Index: Ac0qUv1qciE6zQEvQDWI9/qZe4aXIQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D05B7C848@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: Sat, 05 May 2012 00:06:50 -0000 Hi, Is there a way to get the dest UDP port and the well known MAC address that= we are alluding to in the draft-mmm-bfd-on-lags-03 assigned to us now, ins= tead of waiting all the way till it reaches the RFC ed queue? This will hel= p vendors who want an interoperable implementation to come out early, rathe= r than waiting till this publishes as an RFC. Also, can we accept this as a WG document since there is clear consensus on= taking up this work? Cheers, Manav= From d3e3e3@gmail.com Fri May 4 18:30: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 488DE21F84C3 for ; Fri, 4 May 2012 18:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4MhrIqHnabx for ; Fri, 4 May 2012 18:30:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA121F84BF for ; Fri, 4 May 2012 18:30:37 -0700 (PDT) Received: by yenq7 with SMTP id q7so3974800yen.31 for ; Fri, 04 May 2012 18:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jLuC1tkqML6dcH458oeO3GgFJxlVSVNC6+BKP8TykqE=; b=eH+Vx9ksEeb0YJnT+q4E9gw9VPf2Gq7NyNJcH1tZFEVFf8VrB6b0eLr5+O/ReHijRt O43myHjU86M8cacFkXDTHam17wniUgQbJv20gBDYC76OH7KR+9OOAiQnTqnfomS2fMli Es3ouTRD6KSALUd94pROOSwo+KLUs/5Ty+07FB1HJyE7LxJg30GbE7cYTxRprekBBpqd sOaWKWrZwoN5CpaaG9WwneTVINa87dUEpZ76vwamCx1K4OKkZUzOzmQjWd9MrKz1NSOI K2a2Nkay2lT4pW4qQamtmzpELJO0rNwTTVfausDq0qYVXUCjIw48SeqHiyyxKdUWViwN lJPQ== Received: by 10.42.88.135 with SMTP id c7mr4025104icm.57.1336180979598; Fri, 04 May 2012 18:22:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Fri, 4 May 2012 18:22:39 -0700 (PDT) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D05B7C848@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D05B7C848@INBANSXCHMBSA1.in.alcatel-lucent.com> From: Donald Eastlake Date: Fri, 4 May 2012 21:22:39 -0400 Message-ID: Subject: Re: IANA actions and WG document To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sat, 05 May 2012 01:30:38 -0000 So, do you want a unicast or multicast MAC address? Allocation of small blocks, including a single address, is by Expert Review. The idea is that you should fill out the template in RFC 5342 and send it to IANA... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Fri, May 4, 2012 at 8:06 PM, Bhatia, Manav (Manav) wrote: > Hi, > > Is there a way to get the dest UDP port and the well known MAC address th= at we are alluding to in the draft-mmm-bfd-on-lags-03 assigned to us now, i= nstead of waiting all the way till it reaches the RFC ed queue? This will h= elp vendors who want an interoperable implementation to come out early, rat= her than waiting till this publishes as an RFC. > > Also, can we accept this as a WG document since there is clear consensus = on taking up this work? > > Cheers, Manav From manav.bhatia@alcatel-lucent.com Fri May 4 18:39:59 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A831C21F84DF for ; Fri, 4 May 2012 18:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.449 X-Spam-Level: X-Spam-Status: No, score=-8.449 tagged_above=-999 required=5 tests=[AWL=-1.850, 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 Cm0l862VMv9C for ; Fri, 4 May 2012 18:39:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5C58521F84DE for ; Fri, 4 May 2012 18:39:53 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q451dmqT021489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 20:39:51 -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 q451dlg0005920 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 5 May 2012 07:09:47 +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, 5 May 2012 07:09:47 +0530 From: "Bhatia, Manav (Manav)" To: Donald Eastlake Date: Sat, 5 May 2012 07:10:37 +0530 Subject: RE: IANA actions and WG document Thread-Topic: IANA actions and WG document Thread-Index: Ac0qXZ+q6xWa2gilQ12Za1mIiH+EEwAAfWzA Message-ID: <7C362EEF9C7896468B36C9B79200D8350D05B7C852@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D05B7C848@INBANSXCHMBSA1.in.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 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: Sat, 05 May 2012 01:39:59 -0000 A Unicast MAC should do.=20 Thanks for the info. I will send a note to IANA once this gets accepted as = a WG document.=20 Cheers, Manav > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 > Sent: Saturday, May 05, 2012 6:53 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: IANA actions and WG document >=20 > So, do you want a unicast or multicast MAC address?=20 > Allocation of small blocks, including a single address, is by=20 > Expert Review. The idea is that you should fill out the=20 > template in RFC 5342 and send it to IANA... >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) > =A0155 Beaver Street,=A0Milford, MA 01757 USA > =A0d3e3e3@gmail.com >=20 >=20 > On Fri, May 4, 2012 at 8:06 PM, Bhatia, Manav (Manav)=20 > wrote: > > Hi, > > > > Is there a way to get the dest UDP port and the well known=20 > MAC address that we are alluding to in the=20 > draft-mmm-bfd-on-lags-03 assigned to us now, instead of=20 > waiting all the way till it reaches the RFC ed queue? This=20 > will help vendors who want an interoperable implementation to=20 > come out early, rather than waiting till this publishes as an RFC. > > > > Also, can we accept this as a WG document since there is=20 > clear consensus on taking up this work? > > > > Cheers, Manav > = From marc@sniff.de Sat May 5 11:21: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 537D421F85E7 for ; Sat, 5 May 2012 11:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.148, 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 7RG8r2BYaRpT for ; Sat, 5 May 2012 11:21:48 -0700 (PDT) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D11F21F85D2 for ; Sat, 5 May 2012 11:21:48 -0700 (PDT) Received: from [127.0.0.1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 7AAF62AA0F; Sat, 5 May 2012 18:21:45 +0000 (GMT) Subject: Re: I-D Action: draft-akiya-bfd-intervals-01.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: <20120504190236.GD4110@pfrc> Date: Sat, 5 May 2012 20:21:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BB3EF3F-1B6B-47DF-B97E-2F90D12378C7@sniff.de> References: <20120425232912.26402.17632.idtracker@ietfa.amsl.com> <20120504190236.GD4110@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1084) 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: Sat, 05 May 2012 18:21:49 -0000 Hello Jeff, thanks for your comments. Actually I should have used a MUST instead of must. You say it's = demanding but keep in mind that having a guarantee that certain = intervals are supported is exactly the reason why we wrote the draft. Re-reading our draft maybe this is where a misunderstanding is caused: = what we wanted to say is The problem can be reduced by defining interval values that MUST be supported by an implementation when the value is equal or larger than the fastest, i.e. lowest, interval a particular BFD implementation supports.=20 I mentioned this lower limit condition in the abstract but not = explicitly later again. Actually it makes it a terribly long sentence. = Or maybe as an alternative, providing the idea in some "vague" English = and then a technical definition: The problem can be reduced by defining interval values that are supported by all implementations. Then the adjustment mechanism could find a commonly supported interval without deviating too much from the original request. In technical terms the requirement is as follows: a BFD = implementation MUST support all values in the set of Standard interval values which are equal or larger than the fastest, i.e. lowest, interval the particular BFD implementation supports. To be very clear: while the set of Standard interval values we propose = contains 3.3msec, 10msec and other fast intervals I'm not saying that = every vendor must support these values. Would be shooting into my own = foot as some of my own products have fastest intervals of 50 or 100msec = :-) > "The problem can be reduced by defining a set of standardized = intervals. > Implementations that are capable of supporting one of the standardized > intervals SHOULD do so. The way I read this would mean that vendor "A" in our example in section = 2 would be compatible with such a statement - vendor "A" supports = 100msec, which is in the set of standardized intervals. But Nobo and me = argued that "A" is kind of a troublemaker by not supporting interval = "20msec". Does this make sense to you? Regards, Marc On 2012-05-04, at 21:02 , Jeffrey Haas wrote: > Marc, >=20 > On Thu, Apr 26, 2012 at 01:43:15AM +0200, Marc Binderberger wrote: >> after some feedback Nobo and me updated the document. We changed the = wording from "Mandatory interval support" towards "Standardized interval = support". The "Mandatory" was an unfortunate word choice and caused = confusion; my apology for this. >>=20 >> We also added some clarifications. >>=20 >> To summarize this draft is about an interoperability problem between = BFD speakers when the number of supported intervals is small, as it may = happen with hardware-based BFD. Such implementations are more difficult = to upgrade (or even impossible), compared to software on general-purpose = CPU, thus the attempt to avoid a foreseeable problem. >>=20 >>=20 >> Discussions are welcome :-) >=20 > A good step in the right direction. Minor comments: >=20 > : 3. Well-defined, standardized intervals > :=20 > : The problem can be reduced by defining interval values that must = be > : supported by all implementations. Then the adjustment mechanism > : could find a commonly supported interval without deviating too = much > : from the original request. > :=20 > : The proposed set of Standard interval values is: 3.3msec, 10msec, > : 20msec, 50msec, 300msec and 1sec. >=20 > Your first sentence, while a lower-case "must", still seems very = demanding. > Consider something like: >=20 > "The problem can be reduced by defining a set of standardized = intervals. > Implementations that are capable of supporting one of the standardized > intervals SHOULD do so. Implementations may then quickly converge on = a > commonly supported interval without deviating too much from the = original > request." >=20 > -- Jeff (speaking as an individual contributor) >=20 -- Marc Binderberger From jhaas@slice.pfrc.org Mon May 7 11:25: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 7143821F869C for ; Mon, 7 May 2012 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.975 X-Spam-Level: X-Spam-Status: No, score=-101.975 tagged_above=-999 required=5 tests=[AWL=0.290, 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 RUc-QYIafHCr for ; Mon, 7 May 2012 11:25:08 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D898A21F8693 for ; Mon, 7 May 2012 11:25:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 804EBD0E9; Mon, 7 May 2012 14:25:07 -0400 (EDT) Date: Mon, 7 May 2012 14:25:07 -0400 From: Jeffrey Haas To: Marc Binderberger Subject: Re: I-D Action: draft-akiya-bfd-intervals-01.txt Message-ID: <20120507182507.GC16863@pfrc> References: <20120425232912.26402.17632.idtracker@ietfa.amsl.com> <20120504190236.GD4110@pfrc> <3BB3EF3F-1B6B-47DF-B97E-2F90D12378C7@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3BB3EF3F-1B6B-47DF-B97E-2F90D12378C7@sniff.de> 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, 07 May 2012 18:25:08 -0000 On Sat, May 05, 2012 at 08:21:40PM +0200, Marc Binderberger wrote: > I mentioned this lower limit condition in the abstract but not explicitly later again. Actually it makes it a terribly long sentence. Or maybe as an alternative, providing the idea in some "vague" English and then a technical definition: > > The problem can be reduced by defining interval values that are > supported by all implementations. Then the adjustment mechanism > could find a commonly supported interval without deviating too much > from the original request. > > In technical terms the requirement is as follows: a BFD implementation > MUST support all values in the set of Standard interval values which > are equal or larger than the fastest, i.e. lowest, interval the > particular BFD implementation supports. I believe the above two paragraphs probably are closer to saying what you intend to say. One of the reasons I argue for SHOULD is somewhat vaguely based on concerns I have whether implementations can fully support the rate rather than simply get "close enough". Consider the following contrived example: One of our standard rates is 10msec. Due to the clock inputs for a given chipset providing hardware based BFD, the interval is 9.5msec. Should the implementation say "I can do 10msec" or report its actual 9.5msec? To a large extent, if you're working to be compliant with RFC 5880, you already report a jitter (up to 25%) over your lowest possible detection time. If you can only really detect things at 10msec, you probably should report 12.5msec as part of BFD session setup. (Or 10% jitter at detection interval of 1). So, what your draft is really saying is "for each interval in set of standardized intervals, your implementation must support an actual detection interval a jitter value smaller than the reported interval". It still seems to be worthwhile determining some standardized intervals for all the reasons you cite. However, by the above observations, it's probably not worth trying to be too picky about the values as long as they are within mandated jitter. -- Jeff From adrian@olddog.co.uk Fri May 11 14:42: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 69BC59E8009 for ; Fri, 11 May 2012 14:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 q-XDPzfyPX3X for ; Fri, 11 May 2012 14:42:08 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD519E800A for ; Fri, 11 May 2012 14:42:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4BLg4eK000697; Fri, 11 May 2012 22:42:04 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4BLg26R000677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 May 2012 22:42:03 +0100 From: "Adrian Farrel" To: Subject: Change of AD for BFD Date: Fri, 11 May 2012 22:41:59 +0100 Message-ID: <040401cd2fbe$e5fd5910$b1f80b30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0vvrqL4HL80dzlRZmqWLaDAXym6w== Content-Language: en-gb Cc: bfd-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:42:08 -0000 Hi BFD, Stewart and I are load balancing again, and you are the fortunate/unfortunate beneficiaries. We will move BFD (back) to my "care" and I will pick up any AD actions that are outstanding. Let me know if you believe there are any issues that need my attention. Thanks, Adrian From d3e3e3@gmail.com Wed May 23 14:23:22 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69C711E8080 for ; Wed, 23 May 2012 14:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.134 X-Spam-Level: X-Spam-Status: No, score=-103.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1goJdTHBGdGj for ; Wed, 23 May 2012 14:23:22 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFAE21F850B for ; Wed, 23 May 2012 14:23:22 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8254054ggn.31 for ; Wed, 23 May 2012 14:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2CZtsDyUBNJbbE2uyAzsaMk14HhR/miReJLrHOTTOJ4=; b=V3bjmmVDUYUBQxbmChrS1xMdJU+6y0zMu7bleMq6qu17N35oN+jVzoggzv5I4bFkk7 G3QDqTAI2fYEmmG6MR4fIF3YuSsdQVpJWCk0d5HpUEYOPvbxykNUUhbRogcOwYBgVGPy rLcWjCiX8jiUIvD3EBBB++oetcYo1uewR+rAFa+0GMPRI7ZKCZKqKehlxmr67SRpT7B0 T47mfyCEWiPUp60fxHj48y9q6l9989O603vtWWV52N4u6+OV8+RJwm8PeLIeqX8gbf+O /wqtzoTWViVWSoGCRKbURn5vi3ofY62gZgHJGiJ9Pob7TWKN24autwv8MfrTY7PTrY+C fCjA== Received: by 10.50.179.103 with SMTP id df7mr14514718igc.35.1337808201338; Wed, 23 May 2012 14:23:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.59.201 with HTTP; Wed, 23 May 2012 14:23:01 -0700 (PDT) In-Reply-To: <20120523211548.28200.46941.idtracker@ietfa.amsl.com> References: <20120523211548.28200.46941.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Wed, 23 May 2012 17:23:01 -0400 Message-ID: Subject: Fwd: Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) to Proposed Standard To: rtg-bfd WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: trill-chairs@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:23:22 -0000 Hi, This draft passed TRILL WG Last Call (notice of which was previous posted to the BFD WG) and is now in IETF Last Call. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com ---------- Forwarded message ---------- From: The IESG Date: Wed, May 23, 2012 at 5:15 PM Subject: Last Call: (TRILL: Bidirectional Forwarding Detection (BFD) Support) to Proposed Standard To: IETF-Announce Cc: trill@ietf.org The IESG has received a request from the Transparent Interconnection of Lots of Links WG (trill) to consider the following document: - 'TRILL: Bidirectional Forwarding Detection (BFD) Support' =A0 as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract =A0 This document specifies use of the BFD (Bidirectional Forwarding =A0 Detection) protocol in RBridge campuses based on the Rbridge Channel =A0 extension to the the TRILL (TRansparent Interconnection of Lots of =A0 Links) protocol. =A0 BFD is a widely deployed OAM (Operations, Administration, and =A0 Maintenance) mechanism in IP and MPLS networks, using UDP and ACH =A0 encapsulation respectively. =A0This document specifies the BFD =A0 encapsulation over TRILL. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/ballot/ No IPR declarations have been submitted directly on this I-D.