From jhaas@slice.pfrc.org Wed May 4 08:25:32 2011 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 90D74E07A1 for ; Wed, 4 May 2011 08:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozAcY8scJ0YF for ; Wed, 4 May 2011 08:25:32 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 41A5FE078F for ; Wed, 4 May 2011 08:25:26 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9D0422240FA; Wed, 4 May 2011 15:26:01 +0000 (UTC) Date: Wed, 4 May 2011 15:26:01 +0000 From: Jeffrey Haas To: John E Drake Subject: Re: [RTG-DIR] bfd working group last call on draft-ietf-mpls-tp-cc-cv-rdi-03 Message-ID: <20110504152601.GA20861@slice> References: <20110419195432.GA19083@slice> <5E893DB832F57341992548CDBB333163A0971198BB@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E893DB832F57341992548CDBB333163A0971198BB@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Jeff Haas , David Ward , Ross Callon , "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, 04 May 2011 15:25:32 -0000 On Wed, Apr 20, 2011 at 02:07:46PM -0700, John E Drake wrote: > I had sent an email to Jeff asking about his suggestion to use Demand to support Independent Mode and telling him about our new proposal for supporting P/F. After discussing my comments on the use of Demand mode with the authors of draft-ietf-mpls-tp-cc-cv-rdi, here is a rough summary of our consensus: - I still believe demand mode has cleaner semantics for the intended use case. This is partially due to a minor ambiguity of how a the Required Min Rx interval of 0 is specified in the section on holding down BFD sessions in RFC 5880. - Even so, the semantics are clear enough, especially as clarified in the cc-cv draft. I thus withdraw my concerns on the 0 min rx interval. With the poll sequence now intended for the updated draft, my biggest concern for general BFD interoperability when not using Independent mode is addressed. -- Jeff From jhaas@slice.pfrc.org Sat May 7 06:54:39 2011 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 7D757E0651 for ; Sat, 7 May 2011 06:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.033 X-Spam-Level: X-Spam-Status: No, score=-102.033 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny28WUlVrs-c for ; Sat, 7 May 2011 06:54:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D0824E06F2 for ; Sat, 7 May 2011 06:54:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1B8982240D0; Sat, 7 May 2011 13:35:45 +0000 (UTC) Date: Sat, 7 May 2011 13:35:45 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Time for a recharter Message-ID: <20110507133545.GB17459@slice> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" 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: Sat, 07 May 2011 13:54:39 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Working Group, As our ADs have reminded us, we're in need of a re-charter for the working group. Based on the minutes from our last session and some items the chairs have been approached about, please find a possible draft charter for discussion. Note that milestones have yet to be determined. Commentary on the draft charter's work items: - The MIB work is a lingering work item from our prior charter. The current status is that it's ready for last call but we'd like to hold off on doing that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-rdi has converged to final nits. IMO, we're very close on that. (This chair would be thrilled to have that work complete prior to the completion of our re-charter.) - We continue to provide a stewardship role for the BFD core protocol. As such, we'll be assisting other working groups with the use of BFD in their applications. This covers several of the items in the draft charter including DHCP, MPLS-TP and TRILL. - The cryptographic work was presented at our last session. We had reasonable consensus about adopting this as a working group item even if there was some contention on the details. As part of this re-chartering we would be formally be requesting this to be adopted as a WG item. - The P2MP work was deferred from the original charter until the base BFD protocol was solidified. Send your comments on the draft charter to the mailing list. Please annotate your comments specifically with whether this is an edit to the charter text or a suggested addition or deletion for working group items. -- Jeff --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bfd-charter.txt" Bidirectional Forwarding Detection (bfd) Description of Working Group The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is chartered to complete the following work items: 1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying-based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using SHA-2 and HMAC-SHA-2 using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to-multipoint links and networks. 4. Provide a mechanism for bootstrapping BFD on dynamically configured edge devices using DHCPv4 and DHCPv6. 5. Assist in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification. 6. Assist with the standardization of the BFD protocol for Trill. --fUYQa+Pmc3FrFX/N-- From d3e3e3@gmail.com Sat May 7 07:27:34 2011 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 DF3E6E06C5 for ; Sat, 7 May 2011 07:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwCoSf6s4Y+y for ; Sat, 7 May 2011 07:27:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C74D4E068B for ; Sat, 7 May 2011 07:27:33 -0700 (PDT) Received: by gwb20 with SMTP id 20so1801732gwb.31 for ; Sat, 07 May 2011 07:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=OWZ6j14VkS92LLxqBkL2zm6F8NJSRiK1xKuzjyLmvKU=; b=SiGtJJUSOwaSfSrqyP+T2P49L1PKHyeK4DuWyuSRnNefrg7T+23udoPJ4UB6Vgwo1A FQoyYqbxoRxFQZT2WbKEhgX3j8n192uJY5ht12HMhRLevfkiQmsEeFkmzbTddkt0dFTr B3GQSk84/D07hACMltt1NgvT4ml5jeJiJa8y8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Iz6miiPAH2c3rnx8Ov7xeSzGEaN2u5ri+k6z/qgNr2pufr+WGzS1cyiGuTrLkfnAss 69AB9C68AO14ZJb6NDZeu3U6Jb/8n9MtsbpvADTVBaLn/g4ONQjTZKcMtPJGIy3ct+Bf owH9NK+YCd2/iMxCy0f5Hx51VWNSoiHwNr0vA= Received: by 10.151.158.6 with SMTP id k6mr3617848ybo.283.1304778451106; Sat, 07 May 2011 07:27:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.42.16 with HTTP; Sat, 7 May 2011 07:27:11 -0700 (PDT) In-Reply-To: <20110506213008.8760.7864.idtracker@ietfa.amsl.com> References: <20110506213008.8760.7864.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Sat, 7 May 2011 10:27:11 -0400 Message-ID: Subject: Fwd: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-bfd-00.txt To: rtg-bfd WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 14:27:35 -0000 FYI 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: Date: Fri, May 6, 2011 at 5:30 PM Subject: [rbridge] I-D ACTION:draft-ietf-trill-rbridge-bfd-00.txt To: i-d-announce@ietf.org Cc: rbridge@postel.org A new Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transparent Interconnection of Lots of Links Working Group of the IETF. =A0 =A0Title =A0 =A0 =A0 =A0 : Rbridges: Bidirectional Forwarding Detection= (BFD) support for TRILL =A0 =A0Author(s) =A0 =A0 : D. Ward, et al =A0 =A0Filename =A0 =A0 =A0: draft-ietf-trill-rbridge-bfd-00.txt =A0 =A0Pages =A0 =A0 =A0 =A0 : 11 =A0 =A0Date =A0 =A0 =A0 =A0 =A0: 2011-05-06 =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 TRILL (TRansparent Interconnection of Lots of Links) =A0 protocol. =A0 BFD is a widely deployed (Operations, Administration and Maintenance) =A0 OAM mechanism in IP and MPLS networks. =A0However, in the present form =A0 a BFD packet cannot be sent over a TRILL network as it is either IP/ =A0 UDP encapsulated or encapsulated directly over Multi Protocol Label =A0 Switching (MPLS) or using Associated Channel Header (ACH) =A0 encapsulation. =A0This document defines BFD encapsulation over TRILL to =A0 address this shortcoming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-bfd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ rbridge mailing list rbridge@postel.org http://mailman.postel.org/mailman/listinfo/rbridge From glen.kent@gmail.com Tue May 10 21:25:01 2011 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 480B2E0722 for ; Tue, 10 May 2011 21:25:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dM2FAqMpnPN for ; Tue, 10 May 2011 21:25:00 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80AFBE06A6 for ; Tue, 10 May 2011 21:25:00 -0700 (PDT) Received: by wyb29 with SMTP id 29so93698wyb.31 for ; Tue, 10 May 2011 21:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8R4YrKl0sqy6MYCzkfmNmpiWkBv15bk6uXJvtc2frTk=; b=ezS6FgxU72elwApO0oDq1mkX1na8RjsC3VUk3X31X+Ie7Z725vB1HDZCWHcoSGElZ6 hvQNG8fcFtKoC4iw57WKOBAl+8C1s8Mx30rA1nCUP6cbcQ6F5pahLucfI/WPYvEo96B9 HyZXtTgcBa2QA4uDaJthFUELfxVKZ3nMzaLY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=l9XhFEl5ef+0LURpYkVlbGzYc9gV5uaRGyo2mogZLLuKzq1FKaCc6nlTsKxCqxSb4i k9kBmo3qF44J67Li+HznexmlIJ6hVaQzO2y29b5JWIrFE58xG+KR/++sjzgIt1ll9c6Q nT0dKOQXjFHshBKmOK24HCZ+qSroirLRRzmhk= MIME-Version: 1.0 Received: by 10.216.69.140 with SMTP id n12mr6116566wed.32.1305087899600; Tue, 10 May 2011 21:24:59 -0700 (PDT) Received: by 10.216.156.13 with HTTP; Tue, 10 May 2011 21:24:59 -0700 (PDT) In-Reply-To: <20110507133545.GB17459@slice> References: <20110507133545.GB17459@slice> Date: Wed, 11 May 2011 09:54:59 +0530 Message-ID: Subject: Re: Time for a recharter From: Glen Kent To: Jeffrey Haas 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: Wed, 11 May 2011 04:25:01 -0000 The proposed charter looks good to me. Glen On Sat, May 7, 2011 at 7:05 PM, Jeffrey Haas wrote: > Working Group, > > As our ADs have reminded us, we're in need of a re-charter for the > working group. =A0Based on the minutes from our last session and some ite= ms > the chairs have been approached about, please find a possible draft chart= er > for discussion. =A0Note that milestones have yet to be determined. > > Commentary on the draft charter's work items: > - The MIB work is a lingering work item from our prior charter. =A0The cu= rrent > =A0status is that it's ready for last call but we'd like to hold off on d= oing > =A0that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-= rdi > =A0has converged to final nits. =A0IMO, we're very close on that. > =A0(This chair would be thrilled to have that work complete prior to the > =A0completion of our re-charter.) > > - We continue to provide a stewardship role for the BFD core protocol. = =A0As > =A0such, we'll be assisting other working groups with the use of BFD in t= heir > =A0applications. =A0This covers several of the items in the draft charter > =A0including DHCP, MPLS-TP and TRILL. > > - The cryptographic work was presented at our last session. =A0We had > =A0reasonable consensus about adopting this as a working group item even = if > =A0there was some contention on the details. =A0As part of this re-charte= ring > =A0we would be formally be requesting this to be adopted as a WG item. > > - The P2MP work was deferred from the original charter until the base BFD > =A0protocol was solidified. > > Send your comments on the draft charter to the mailing list. =A0Please > annotate your comments specifically with whether this is an edit to the > charter text or a suggested addition or deletion for working group items. > > -- Jeff > From jeff.tantsura@ericsson.com Tue May 10 21:26:05 2011 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 35AEDE072C for ; Tue, 10 May 2011 21:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZrsnk9Wq9wN for ; Tue, 10 May 2011 21:26:04 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 91D10E06A6 for ; Tue, 10 May 2011 21:26:04 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p4B4Q2nb027812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 May 2011 23:26:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 11 May 2011 00:26:01 -0400 From: Jeff Tantsura To: Glen Kent , Jeffrey Haas Date: Wed, 11 May 2011 00:26:00 -0400 Subject: RE: Time for a recharter Thread-Topic: Time for a recharter Thread-Index: AcwPk2gpZhUrMv9WTqGPPIo9OJxUvwAABnxA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CAC0A66CD@EUSAACMS0701.eamcs.ericsson.se> References: <20110507133545.GB17459@slice> 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 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 May 2011 04:26:05 -0000 Same here Regards, Jeff =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Glen Kent Sent: Tuesday, May 10, 2011 21:25 To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: Time for a recharter The proposed charter looks good to me. Glen On Sat, May 7, 2011 at 7:05 PM, Jeffrey Haas wrote: > Working Group, > > As our ADs have reminded us, we're in need of a re-charter for the > working group. =A0Based on the minutes from our last session and some ite= ms > the chairs have been approached about, please find a possible draft chart= er > for discussion. =A0Note that milestones have yet to be determined. > > Commentary on the draft charter's work items: > - The MIB work is a lingering work item from our prior charter. =A0The cu= rrent > =A0status is that it's ready for last call but we'd like to hold off on d= oing > =A0that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-= rdi > =A0has converged to final nits. =A0IMO, we're very close on that. > =A0(This chair would be thrilled to have that work complete prior to the > =A0completion of our re-charter.) > > - We continue to provide a stewardship role for the BFD core protocol. = =A0As > =A0such, we'll be assisting other working groups with the use of BFD in t= heir > =A0applications. =A0This covers several of the items in the draft charter > =A0including DHCP, MPLS-TP and TRILL. > > - The cryptographic work was presented at our last session. =A0We had > =A0reasonable consensus about adopting this as a working group item even = if > =A0there was some contention on the details. =A0As part of this re-charte= ring > =A0we would be formally be requesting this to be adopted as a WG item. > > - The P2MP work was deferred from the original charter until the base BFD > =A0protocol was solidified. > > Send your comments on the draft charter to the mailing list. =A0Please > annotate your comments specifically with whether this is an edit to the > charter text or a suggested addition or deletion for working group items. > > -- Jeff > From shane@castlepoint.net Wed May 11 07:32:49 2011 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 E29E0E0773 for ; Wed, 11 May 2011 07:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CEXzEj-LIiq for ; Wed, 11 May 2011 07:32:49 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 89D00E06F6 for ; Wed, 11 May 2011 07:32:46 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 65886268037; Wed, 11 May 2011 08:32:45 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 11 May 2011 08:32:45 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54231; data-bytes=0 Subject: Re: Time for a recharter Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <20110507133545.GB17459@slice> Date: Wed, 11 May 2011 08:32:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110507133545.GB17459@slice> 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: Wed, 11 May 2011 14:32:50 -0000 Jeff, All, I'd like to see if there's interest among WG members to take a look at = [more thoroughly] specifying how BFD may be used to detect availability = of component-links that comprise a LAG or ECMP. The problems I currently face are: a) "Standalone" BFD Asynchronous Mode, the most widely implemented form = of BFD as far as I've seen, will establish a single Control session that = has the same UDP/IP 5-tuple for the life of that particular BFD session. = Unfortunately, the packets from that BFD session will get forwarded = down only a single component-link of the LAG and/or ECMP path, due to = the nature of the stateless load-distribution hash algorithm employed at = forwarding time of the BFD packet. With a large number of = component-links in a single LAG and/or ECMP, this results in not = monitoring a significant number of potential forwarding paths. b) In theory, LACP is already used for this (if/when the = component-links are Ethernet); however, the fast periodic timer for = LACPDU's is 1 second with a 3-second timeout. Hardly sub-second = detection. c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM = (Continuity Check Messages), which are specified to detect physical link = failures sub-second, the configuration of either of these protocols is = massively complex and onerous, (think: several lines of configuration = and associated variables per physical, component-link interface and then = multiply that by the number of component-link interfaces in a single = LAG). It's also worth noting that the 'learning curve' for either of = those protocols is fairly steep, while most IP/MPLS shops are already = familiar with and have been using BFD for several years already. In the "nice to have" category: d) LACP is only designed to work over a set of component-links whose = physical port speeds are identical, (e.g.: all 10 GbE in a single LAG). = It may be useful to have a monitoring protocol that was able to check = availability if/when there are different physical link speeds inside the = same LAG group, e.g.: N x 100 GbE + M x 10 GbE. For now, I'll stop short of suggesting some potential ways that BFD = might be extended to support monitoring of component-links in a LAG = and/or ECMP to first see if there's interest by others in considering = taking on this work. Assuming there is I would be happy to suggest = appropriate scope and milestones of that work. Thanks, -shane On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: > Working Group, >=20 > As our ADs have reminded us, we're in need of a re-charter for the > working group. Based on the minutes from our last session and some = items > the chairs have been approached about, please find a possible draft = charter > for discussion. Note that milestones have yet to be determined. >=20 > Commentary on the draft charter's work items: > - The MIB work is a lingering work item from our prior charter. The = current > status is that it's ready for last call but we'd like to hold off on = doing > that until the MPLS-TP work with relation to = draft-ietf-mpls-tp-cc-cv-rdi > has converged to final nits. IMO, we're very close on that. > (This chair would be thrilled to have that work complete prior to the > completion of our re-charter.) >=20 > - We continue to provide a stewardship role for the BFD core protocol. = As > such, we'll be assisting other working groups with the use of BFD in = their > applications. This covers several of the items in the draft charter > including DHCP, MPLS-TP and TRILL. >=20 > - The cryptographic work was presented at our last session. We had > reasonable consensus about adopting this as a working group item even = if > there was some contention on the details. As part of this = re-chartering > we would be formally be requesting this to be adopted as a WG item. >=20 > - The P2MP work was deferred from the original charter until the base = BFD > protocol was solidified. >=20 > Send your comments on the draft charter to the mailing list. Please=20= > annotate your comments specifically with whether this is an edit to = the > charter text or a suggested addition or deletion for working group = items. >=20 > -- Jeff > From davari@broadcom.com Wed May 11 10:12:51 2011 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 0C2D4E0684 for ; Wed, 11 May 2011 10:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fA55DWm0eP3p for ; Wed, 11 May 2011 10:12:50 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB4CE0718 for ; Wed, 11 May 2011 10:12:47 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 11 May 2011 10:16:07 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 11 May 2011 10:12:39 -0700 From: "Shahram Davari" To: "Shane Amante" , "Jeffrey Haas" Date: Wed, 11 May 2011 10:12:37 -0700 Subject: RE: Time for a recharter Thread-Topic: Time for a recharter Thread-Index: AcwP6FnNMEGxTDB7TI28ChQKyzWLZwAFhIhw Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD695A5C733FB@SJEXCHCCR02.corp.ad.broadcom.com> References: <20110507133545.GB17459@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61D41BDD4NS6598881-01-01 Content-Type: text/plain; charset=us-ascii 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: Wed, 11 May 2011 17:12:51 -0000 Hi Shane, In case of Single-HOP BFD one could use the 127/8 IP address and scan the a= ddress range to exercise the other component links similar to LSP-Ping. Wou= ldn't that solve the problem? Thanks Shahram -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Shane Amante Sent: Wednesday, May 11, 2011 7:33 AM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: Time for a recharter Jeff, All, I'd like to see if there's interest among WG members to take a look at [mor= e thoroughly] specifying how BFD may be used to detect availability of comp= onent-links that comprise a LAG or ECMP. The problems I currently face are: a) "Standalone" BFD Asynchronous Mode, the most widely implemented form of= BFD as far as I've seen, will establish a single Control session that has = the same UDP/IP 5-tuple for the life of that particular BFD session. Unfor= tunately, the packets from that BFD session will get forwarded down only a = single component-link of the LAG and/or ECMP path, due to the nature of the= stateless load-distribution hash algorithm employed at forwarding time of = the BFD packet. With a large number of component-links in a single LAG and= /or ECMP, this results in not monitoring a significant number of potential = forwarding paths. b) In theory, LACP is already used for this (if/when the component-links a= re Ethernet); however, the fast periodic timer for LACPDU's is 1 second wit= h a 3-second timeout. Hardly sub-second detection. c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM (Continu= ity Check Messages), which are specified to detect physical link failures s= ub-second, the configuration of either of these protocols is massively comp= lex and onerous, (think: several lines of configuration and associated vari= ables per physical, component-link interface and then multiply that by the = number of component-link interfaces in a single LAG). It's also worth noti= ng that the 'learning curve' for either of those protocols is fairly steep,= while most IP/MPLS shops are already familiar with and have been using BFD= for several years already. In the "nice to have" category: d) LACP is only designed to work over a set of component-links whose physi= cal port speeds are identical, (e.g.: all 10 GbE in a single LAG). It may = be useful to have a monitoring protocol that was able to check availability= if/when there are different physical link speeds inside the same LAG group= , e.g.: N x 100 GbE + M x 10 GbE. For now, I'll stop short of suggesting some potential ways that BFD might b= e extended to support monitoring of component-links in a LAG and/or ECMP to= first see if there's interest by others in considering taking on this work= . Assuming there is I would be happy to suggest appropriate scope and mile= stones of that work. Thanks, -shane On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: > Working Group, >=20 > As our ADs have reminded us, we're in need of a re-charter for the > working group. Based on the minutes from our last session and some items > the chairs have been approached about, please find a possible draft chart= er > for discussion. Note that milestones have yet to be determined. >=20 > Commentary on the draft charter's work items: > - The MIB work is a lingering work item from our prior charter. The curr= ent > status is that it's ready for last call but we'd like to hold off on doin= g > that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-rdi > has converged to final nits. IMO, we're very close on that. > (This chair would be thrilled to have that work complete prior to the > completion of our re-charter.) >=20 > - We continue to provide a stewardship role for the BFD core protocol. A= s > such, we'll be assisting other working groups with the use of BFD in thei= r > applications. This covers several of the items in the draft charter > including DHCP, MPLS-TP and TRILL. >=20 > - The cryptographic work was presented at our last session. We had > reasonable consensus about adopting this as a working group item even if > there was some contention on the details. As part of this re-chartering > we would be formally be requesting this to be adopted as a WG item. >=20 > - The P2MP work was deferred from the original charter until the base BFD > protocol was solidified. >=20 > Send your comments on the draft charter to the mailing list. Please=20 > annotate your comments specifically with whether this is an edit to the > charter text or a suggested addition or deletion for working group items. >=20 > -- Jeff > From vishwas.ietf@gmail.com Wed May 11 10:37:40 2011 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 69E7AE0684 for ; Wed, 11 May 2011 10:37:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q-tpqzQsjvY for ; Wed, 11 May 2011 10:37:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76737E072B for ; Wed, 11 May 2011 10:37:35 -0700 (PDT) Received: by wyb29 with SMTP id 29so668350wyb.31 for ; Wed, 11 May 2011 10:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=imXJcXgiTLbzGky6jpy3rEw9Gna3e5QBEQwXSe8ojps=; b=itpMNln9TJjp0C3sB481YR4ZLu1gdfW9V/fa3bfe9jajB6gte7cuLCW4fwWx5g67bW wbZ7/F13yALUn9c5BkntAdol4D9zpqsmyWFGUz9jkIS0oa2xER8JKZzUFpoWWhnyxWqN Y7mcUSjCx2JZLVLVVRZVT8D0VlRoD9DJt2zVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tKtDpfU5NcRm31PmYebvn5YS/DMCm9dzhpFvWX+X/A1gvVZK/tG3+JIL+gKxY2+wAZ rSjtgD1XWJRJae4/Iltd2ozOPp8tcfmUrhz+LMgorXqJ1nvcssEMPgHRQF7P+ClVkq7V /lgvW1C1D2EwZEjBZV+u9KIZ2ghuibljBt2Lo= MIME-Version: 1.0 Received: by 10.216.143.74 with SMTP id k52mr770332wej.8.1305135454514; Wed, 11 May 2011 10:37:34 -0700 (PDT) Received: by 10.216.25.83 with HTTP; Wed, 11 May 2011 10:37:34 -0700 (PDT) In-Reply-To: References: <20110507133545.GB17459@slice> Date: Wed, 11 May 2011 10:37:34 -0700 Message-ID: Subject: Re: Time for a recharter From: Vishwas Manral To: Shane Amante Content-Type: multipart/alternative; boundary=0016e6db295a2675fd04a303876c 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 May 2011 17:37:40 -0000 --0016e6db295a2675fd04a303876c Content-Type: text/plain; charset=ISO-8859-1 Hi Shane, You have mentioned things correctly. Also in the standalone mode it may be hard to detect issues if one of the links is still up, we need to run BFD at the layer it is monitoring. I see an additional usecase. Think of SPB using IS-IS, but running over Layer-2 (and probably no IP in the data plane). We need to have a mechanism to encapsulate BFD in Ethernet packets by using an Ether Type. I had suggested this more then a few years back. I know they added it to the odler charter as an exploratory item, but it never got looked at after that. http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00597.html Thanks, Vishwas The problems I currently face are: > a) "Standalone" BFD Asynchronous Mode, the most widely implemented form of > BFD as far as I've seen, will establish a single Control session that has > the same UDP/IP 5-tuple for the life of that particular BFD session. > Unfortunately, the packets from that BFD session will get forwarded down > only a single component-link of the LAG and/or ECMP path, due to the nature > of the stateless load-distribution hash algorithm employed at forwarding > time of the BFD packet. With a large number of component-links in a single > LAG and/or ECMP, this results in not monitoring a significant number of > potential forwarding paths. > b) In theory, LACP is already used for this (if/when the component-links > are Ethernet); however, the fast periodic timer for LACPDU's is 1 second > with a 3-second timeout. Hardly sub-second detection. > c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM > (Continuity Check Messages), which are specified to detect physical link > failures sub-second, the configuration of either of these protocols is > massively complex and onerous, (think: several lines of configuration and > associated variables per physical, component-link interface and then > multiply that by the number of component-link interfaces in a single LAG). > It's also worth noting that the 'learning curve' for either of those > protocols is fairly steep, while most IP/MPLS shops are already familiar > with and have been using BFD for several years already. > > In the "nice to have" category: > d) LACP is only designed to work over a set of component-links whose > physical port speeds are identical, (e.g.: all 10 GbE in a single LAG). It > may be useful to have a monitoring protocol that was able to check > availability if/when there are different physical link speeds inside the > same LAG group, e.g.: N x 100 GbE + M x 10 GbE. > > For now, I'll stop short of suggesting some potential ways that BFD might > be extended to support monitoring of component-links in a LAG and/or ECMP to > first see if there's interest by others in considering taking on this work. > Assuming there is I would be happy to suggest appropriate scope and > milestones of that work. > > Thanks, > > -shane > > > > On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: > > Working Group, > > > > As our ADs have reminded us, we're in need of a re-charter for the > > working group. Based on the minutes from our last session and some items > > the chairs have been approached about, please find a possible draft > charter > > for discussion. Note that milestones have yet to be determined. > > > > Commentary on the draft charter's work items: > > - The MIB work is a lingering work item from our prior charter. The > current > > status is that it's ready for last call but we'd like to hold off on > doing > > that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-rdi > > has converged to final nits. IMO, we're very close on that. > > (This chair would be thrilled to have that work complete prior to the > > completion of our re-charter.) > > > > - We continue to provide a stewardship role for the BFD core protocol. > As > > such, we'll be assisting other working groups with the use of BFD in > their > > applications. This covers several of the items in the draft charter > > including DHCP, MPLS-TP and TRILL. > > > > - The cryptographic work was presented at our last session. We had > > reasonable consensus about adopting this as a working group item even if > > there was some contention on the details. As part of this re-chartering > > we would be formally be requesting this to be adopted as a WG item. > > > > - The P2MP work was deferred from the original charter until the base BFD > > protocol was solidified. > > > > Send your comments on the draft charter to the mailing list. Please > > annotate your comments specifically with whether this is an edit to the > > charter text or a suggested addition or deletion for working group items. > > > > -- Jeff > > > > --0016e6db295a2675fd04a303876c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shane,
=A0
You have mentioned things correctly. Also in the standalone mode it ma= y be hard to detect issues if one of the links is still up, we need to run = BFD at the layer it is monitoring.
=A0
I see an additional usecase. Think of SPB using IS-IS, but running ove= r Layer-2 (and probably no IP in the data plane). We need to have a mechani= sm to encapsulate BFD in Ethernet packets by using an Ether Type.
=A0
I had suggested this more then a few years back.=A0I know they added i= t to the odler charter as an exploratory item, but it never got looked at a= fter that.
=A0
Thanks,
Vishwas

The problems I currently face ar= e:
a) =A0"Standalone" BFD Asynchronous Mode, the most widely i= mplemented form of BFD as far as I've seen, will establish a single Con= trol session that has the same UDP/IP 5-tuple for the life of that particul= ar BFD session. =A0Unfortunately, the packets from that BFD session will ge= t forwarded down only a single component-link of the LAG and/or ECMP path, = due to the nature of the stateless load-distribution hash algorithm employe= d at forwarding time of the BFD packet. =A0With a large number of component= -links in a single LAG and/or ECMP, this results in not monitoring a signif= icant number of potential forwarding paths.
b) =A0In theory, LACP is already= used for this (if/when the component-links are Ethernet); however, the fas= t periodic timer for LACPDU's is 1 second with a 3-second timeout. =A0H= ardly sub-second detection.
c) =A0While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM (Conti= nuity Check Messages), which are specified to detect physical link failures= sub-second, the configuration of either of these protocols is massively co= mplex and onerous, (think: several lines of configuration and associated va= riables per physical, component-link interface and then multiply that by th= e number of component-link interfaces in a single LAG). =A0It's also wo= rth noting that the 'learning curve' for either of those protocols = is fairly steep, while most IP/MPLS shops are already familiar with and hav= e been using BFD for several years already.

In the "nice to have" category:
d) =A0LACP is only designe= d to work over a set of component-links whose physical port speeds are iden= tical, (e.g.: all 10 GbE in a single LAG). =A0It may be useful to have a mo= nitoring protocol that was able to check availability if/when there are dif= ferent physical link speeds inside the same LAG group, e.g.: N x 100 GbE + = M x 10 GbE.

For now, I'll stop short of suggesting some potential ways that BFD= might be extended to support monitoring of component-links in a LAG and/or= ECMP to first see if there's interest by others in considering taking = on this work. =A0Assuming there is I would be happy to suggest appropriate = scope and milestones of that work.

Thanks,

-shane



On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote:
> Wo= rking Group,
>
> As our ADs have reminded us, we're in need= of a re-charter for the
> working group. =A0Based on the minutes fro= m our last session and some items
> the chairs have been approached about, please find a possible draft ch= arter
> for discussion. =A0Note that milestones have yet to be determ= ined.
>
> Commentary on the draft charter's work items:
> - The MIB work is a lingering work item from our prior charter. =A0The= current
> status is that it's ready for last call but we'd l= ike to hold off on doing
> that until the MPLS-TP work with relation = to draft-ietf-mpls-tp-cc-cv-rdi
> has converged to final nits. =A0IMO, we're very close on that.
= > (This chair would be thrilled to have that work complete prior to the<= br>> completion of our re-charter.)
>
> - We continue to pro= vide a stewardship role for the BFD core protocol. =A0As
> such, we'll be assisting other working groups with the use of BFD = in their
> applications. =A0This covers several of the items in the d= raft charter
> including DHCP, MPLS-TP and TRILL.
>
> - T= he cryptographic work was presented at our last session. =A0We had
> reasonable consensus about adopting this as a working group item even = if
> there was some contention on the details. =A0As part of this re-= chartering
> we would be formally be requesting this to be adopted as= a WG item.
>
> - The P2MP work was deferred from the original charter until t= he base BFD
> protocol was solidified.
>
> Send your comm= ents on the draft charter to the mailing list. =A0Please
> annotate y= our comments specifically with whether this is an edit to the
> charter text or a suggested addition or deletion for working group ite= ms.
>
> -- Jeff
> <bfd-charter.txt>
=

--0016e6db295a2675fd04a303876c-- From shane@castlepoint.net Wed May 11 10:48:06 2011 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 1B496E0878 for ; Wed, 11 May 2011 10:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xxe2pDDMyuX for ; Wed, 11 May 2011 10:48:05 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 55E73E06C6 for ; Wed, 11 May 2011 10:48:05 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 12E61268037; Wed, 11 May 2011 11:48:05 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 11 May 2011 11:48:05 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=55836; data-bytes=0 Subject: Re: Time for a recharter Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD695A5C733FB@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 11 May 2011 11:48:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0ADCE0A9-3BE7-4779-81C0-227FC79B1AC9@castlepoint.net> References: <20110507133545.GB17459@slice> <2C2F1EBA8050E74EA81502D5740B4BD695A5C733FB@SJEXCHCCR02.corp.ad.broadcom.com> To: Shahram Davari 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: Wed, 11 May 2011 17:48:06 -0000 Hi Shahram, On May 11, 2011, at 11:12 AM, Shahram Davari wrote: > Hi Shane, >=20 > In case of Single-HOP BFD one could use the 127/8 IP address and scan = the address range to exercise the other component links similar to = LSP-Ping. Wouldn't that solve the problem? A similar suggestion was provided off-list to me by John Drake. If there was MPLS encapsulation on the link that would work, (although = I'm not sure the details of feeding the discovery of the component-links = from something like LSP-ping to BFD are [adequately] specified, but = perhaps I'm misinformed?). However, that wouldn't work when the encapsulation is IP-only, i.e.: PE = <-> CE (IPVPN) or ASBR <-> ASBR. -shane > Thanks > Shahram >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante > Sent: Wednesday, May 11, 2011 7:33 AM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: Time for a recharter >=20 > Jeff, All, >=20 > I'd like to see if there's interest among WG members to take a look at = [more thoroughly] specifying how BFD may be used to detect availability = of component-links that comprise a LAG or ECMP. >=20 > The problems I currently face are: > a) "Standalone" BFD Asynchronous Mode, the most widely implemented = form of BFD as far as I've seen, will establish a single Control session = that has the same UDP/IP 5-tuple for the life of that particular BFD = session. Unfortunately, the packets from that BFD session will get = forwarded down only a single component-link of the LAG and/or ECMP path, = due to the nature of the stateless load-distribution hash algorithm = employed at forwarding time of the BFD packet. With a large number of = component-links in a single LAG and/or ECMP, this results in not = monitoring a significant number of potential forwarding paths. > b) In theory, LACP is already used for this (if/when the = component-links are Ethernet); however, the fast periodic timer for = LACPDU's is 1 second with a 3-second timeout. Hardly sub-second = detection. > c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM = (Continuity Check Messages), which are specified to detect physical link = failures sub-second, the configuration of either of these protocols is = massively complex and onerous, (think: several lines of configuration = and associated variables per physical, component-link interface and then = multiply that by the number of component-link interfaces in a single = LAG). It's also worth noting that the 'learning curve' for either of = those protocols is fairly steep, while most IP/MPLS shops are already = familiar with and have been using BFD for several years already. >=20 > In the "nice to have" category: > d) LACP is only designed to work over a set of component-links whose = physical port speeds are identical, (e.g.: all 10 GbE in a single LAG). = It may be useful to have a monitoring protocol that was able to check = availability if/when there are different physical link speeds inside the = same LAG group, e.g.: N x 100 GbE + M x 10 GbE. >=20 > For now, I'll stop short of suggesting some potential ways that BFD = might be extended to support monitoring of component-links in a LAG = and/or ECMP to first see if there's interest by others in considering = taking on this work. Assuming there is I would be happy to suggest = appropriate scope and milestones of that work. >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 > On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: >> Working Group, >>=20 >> As our ADs have reminded us, we're in need of a re-charter for the >> working group. Based on the minutes from our last session and some = items >> the chairs have been approached about, please find a possible draft = charter >> for discussion. Note that milestones have yet to be determined. >>=20 >> Commentary on the draft charter's work items: >> - The MIB work is a lingering work item from our prior charter. The = current >> status is that it's ready for last call but we'd like to hold off on = doing >> that until the MPLS-TP work with relation to = draft-ietf-mpls-tp-cc-cv-rdi >> has converged to final nits. IMO, we're very close on that. >> (This chair would be thrilled to have that work complete prior to the >> completion of our re-charter.) >>=20 >> - We continue to provide a stewardship role for the BFD core = protocol. As >> such, we'll be assisting other working groups with the use of BFD in = their >> applications. This covers several of the items in the draft charter >> including DHCP, MPLS-TP and TRILL. >>=20 >> - The cryptographic work was presented at our last session. We had >> reasonable consensus about adopting this as a working group item even = if >> there was some contention on the details. As part of this = re-chartering >> we would be formally be requesting this to be adopted as a WG item. >>=20 >> - The P2MP work was deferred from the original charter until the base = BFD >> protocol was solidified. >>=20 >> Send your comments on the draft charter to the mailing list. Please=20= >> annotate your comments specifically with whether this is an edit to = the >> charter text or a suggested addition or deletion for working group = items. >>=20 >> -- Jeff >> >=20 >=20 >=20 From davari@broadcom.com Wed May 11 10:54:37 2011 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 36492E0889 for ; Wed, 11 May 2011 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GQCw724Xxtt for ; Wed, 11 May 2011 10:54:36 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6790DE0887 for ; Wed, 11 May 2011 10:54:36 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 11 May 2011 10:58:09 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Wed, 11 May 2011 10:54:19 -0700 From: "Shahram Davari" To: "Shane Amante" Date: Wed, 11 May 2011 10:54:18 -0700 Subject: RE: Time for a recharter Thread-Topic: Time for a recharter Thread-Index: AcwQA5x6l8v8DvhyR0i/+nFG2m55ZQAADSkQ Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD695A5C7344C@SJEXCHCCR02.corp.ad.broadcom.com> References: <20110507133545.GB17459@slice> <2C2F1EBA8050E74EA81502D5740B4BD695A5C733FB@SJEXCHCCR02.corp.ad.broadcom.com> <0ADCE0A9-3BE7-4779-81C0-227FC79B1AC9@castlepoint.net> In-Reply-To: <0ADCE0A9-3BE7-4779-81C0-227FC79B1AC9@castlepoint.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 61D411BA1IC6375831-01-01 Content-Type: text/plain; charset=us-ascii 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: Wed, 11 May 2011 17:54:37 -0000 Hi Shane, -----Original Message----- From: Shane Amante [mailto:shane@castlepoint.net]=20 Sent: Wednesday, May 11, 2011 10:48 AM To: Shahram Davari Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: Re: Time for a recharter Hi Shahram, On May 11, 2011, at 11:12 AM, Shahram Davari wrote: > Hi Shane, >=20 > In case of Single-HOP BFD one could use the 127/8 IP address and scan the= address range to exercise the other component links similar to LSP-Ping. W= ouldn't that solve the problem? A similar suggestion was provided off-list to me by John Drake. If there was MPLS encapsulation on the link that would work, (although I'm = not sure the details of feeding the discovery of the component-links from s= omething like LSP-ping to BFD are [adequately] specified, but perhaps I'm m= isinformed?). SD> This won't require any input from LSP-Ping. The procedure would be to c= hange the Destination IP address for every BFD packet and scan through the = 127/8 range. Almost all hashing algorithms use the IP-DA for hashing and th= erefore eventually all paths (component links) will be exercised. However, that wouldn't work when the encapsulation is IP-only, i.e.: PE <->= CE (IPVPN) or ASBR <-> ASBR. Yes, that is correct since 127/8 is not a valid IP address on the link. How= ever I am not sure why one would need to quickly detect a component link do= wn in case of IP routing, since the router won't be able to reroute the pac= ket anyway. Thanks Shahram=20 -shane > Thanks > Shahram >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Shane Amante > Sent: Wednesday, May 11, 2011 7:33 AM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: Time for a recharter >=20 > Jeff, All, >=20 > I'd like to see if there's interest among WG members to take a look at [m= ore thoroughly] specifying how BFD may be used to detect availability of co= mponent-links that comprise a LAG or ECMP. >=20 > The problems I currently face are: > a) "Standalone" BFD Asynchronous Mode, the most widely implemented form = of BFD as far as I've seen, will establish a single Control session that ha= s the same UDP/IP 5-tuple for the life of that particular BFD session. Unf= ortunately, the packets from that BFD session will get forwarded down only = a single component-link of the LAG and/or ECMP path, due to the nature of t= he stateless load-distribution hash algorithm employed at forwarding time o= f the BFD packet. With a large number of component-links in a single LAG a= nd/or ECMP, this results in not monitoring a significant number of potentia= l forwarding paths. > b) In theory, LACP is already used for this (if/when the component-links= are Ethernet); however, the fast periodic timer for LACPDU's is 1 second w= ith a 3-second timeout. Hardly sub-second detection. > c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM (Conti= nuity Check Messages), which are specified to detect physical link failures= sub-second, the configuration of either of these protocols is massively co= mplex and onerous, (think: several lines of configuration and associated va= riables per physical, component-link interface and then multiply that by th= e number of component-link interfaces in a single LAG). It's also worth no= ting that the 'learning curve' for either of those protocols is fairly stee= p, while most IP/MPLS shops are already familiar with and have been using B= FD for several years already. >=20 > In the "nice to have" category: > d) LACP is only designed to work over a set of component-links whose phy= sical port speeds are identical, (e.g.: all 10 GbE in a single LAG). It ma= y be useful to have a monitoring protocol that was able to check availabili= ty if/when there are different physical link speeds inside the same LAG gro= up, e.g.: N x 100 GbE + M x 10 GbE. >=20 > For now, I'll stop short of suggesting some potential ways that BFD might= be extended to support monitoring of component-links in a LAG and/or ECMP = to first see if there's interest by others in considering taking on this wo= rk. Assuming there is I would be happy to suggest appropriate scope and mi= lestones of that work. >=20 > Thanks, >=20 > -shane >=20 >=20 >=20 > On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: >> Working Group, >>=20 >> As our ADs have reminded us, we're in need of a re-charter for the >> working group. Based on the minutes from our last session and some item= s >> the chairs have been approached about, please find a possible draft char= ter >> for discussion. Note that milestones have yet to be determined. >>=20 >> Commentary on the draft charter's work items: >> - The MIB work is a lingering work item from our prior charter. The cur= rent >> status is that it's ready for last call but we'd like to hold off on doi= ng >> that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-rd= i >> has converged to final nits. IMO, we're very close on that. >> (This chair would be thrilled to have that work complete prior to the >> completion of our re-charter.) >>=20 >> - We continue to provide a stewardship role for the BFD core protocol. = As >> such, we'll be assisting other working groups with the use of BFD in the= ir >> applications. This covers several of the items in the draft charter >> including DHCP, MPLS-TP and TRILL. >>=20 >> - The cryptographic work was presented at our last session. We had >> reasonable consensus about adopting this as a working group item even if >> there was some contention on the details. As part of this re-chartering >> we would be formally be requesting this to be adopted as a WG item. >>=20 >> - The P2MP work was deferred from the original charter until the base BF= D >> protocol was solidified. >>=20 >> Send your comments on the draft charter to the mailing list. Please=20 >> annotate your comments specifically with whether this is an edit to the >> charter text or a suggested addition or deletion for working group items= . >>=20 >> -- Jeff >> >=20 >=20 >=20 From vishwas.ietf@gmail.com Wed May 11 11:05:06 2011 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 07BD0E076D for ; Wed, 11 May 2011 11:05:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEGOY7negH6o for ; Wed, 11 May 2011 11:05:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC58E07F5 for ; Wed, 11 May 2011 11:05:04 -0700 (PDT) Received: by wyb29 with SMTP id 29so689280wyb.31 for ; Wed, 11 May 2011 11:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cI5cUQUhCEjaKtQmLAQk+X1hAgi3Up/m5peOqd/jv/Q=; b=tp+ZrU8jl8+qBkiIHebs30aGE7V1JIt187BIIo030uRo+hiFuHuQ+Pl/Qxr24UuA28 ZuTFJlAd+k/1/T+UwqMevVrJ/Fx9FEKFC93d9B4iEhJfWrSKxn2Ajy8syseomIM/KplD 8MVWRl35YwRQ5RIosob2HS/Z80ab+wFmhZyZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Aw7Bj/x76BmAGx5NR3cvQPYfHk6v0NtsVc+Yndowcc7Xb4m5rP/8qtCIn+CniPMA/y 94BeUkVKCRwUBpexoww29lA0sBoYwAAZjRXlGJtm+1dvXbs//jasoSWv6V9pUTTDAj0f LEOp5PiScgqcba88XtBiL66kNhT7sRzUN50NE= MIME-Version: 1.0 Received: by 10.216.143.74 with SMTP id k52mr797527wej.8.1305137103164; Wed, 11 May 2011 11:05:03 -0700 (PDT) Received: by 10.216.25.83 with HTTP; Wed, 11 May 2011 11:05:03 -0700 (PDT) In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD695A5C7344C@SJEXCHCCR02.corp.ad.broadcom.com> References: <20110507133545.GB17459@slice> <2C2F1EBA8050E74EA81502D5740B4BD695A5C733FB@SJEXCHCCR02.corp.ad.broadcom.com> <0ADCE0A9-3BE7-4779-81C0-227FC79B1AC9@castlepoint.net> <2C2F1EBA8050E74EA81502D5740B4BD695A5C7344C@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 11 May 2011 11:05:03 -0700 Message-ID: Subject: Re: Time for a recharter From: Vishwas Manral To: Shahram Davari Content-Type: multipart/alternative; boundary=0016e6db295a6ad73b04a303e986 Cc: Shane Amante , "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 May 2011 18:05:06 -0000 --0016e6db295a6ad73b04a303e986 Content-Type: text/plain; charset=ISO-8859-1 Hi Shahram, I see 2 issues: 1. As you mentioned "almost" all paths will be exercised (based on IP-DA). 2. We are running the OAM at a higher layer, which could mean that some failures may be triggered even when there is no failure in LAG. Also note not all LAG's are Layer-3 and may not be using IP in the data plane. Thanks, Vishwas On Wed, May 11, 2011 at 10:54 AM, Shahram Davari wrote: > Hi Shane, > > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net] > Sent: Wednesday, May 11, 2011 10:48 AM > To: Shahram Davari > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: Time for a recharter > > Hi Shahram, > > On May 11, 2011, at 11:12 AM, Shahram Davari wrote: > > Hi Shane, > > > > In case of Single-HOP BFD one could use the 127/8 IP address and scan the > address range to exercise the other component links similar to LSP-Ping. > Wouldn't that solve the problem? > > A similar suggestion was provided off-list to me by John Drake. > > If there was MPLS encapsulation on the link that would work, (although I'm > not sure the details of feeding the discovery of the component-links from > something like LSP-ping to BFD are [adequately] specified, but perhaps I'm > misinformed?). > > SD> This won't require any input from LSP-Ping. The procedure would be to > change the Destination IP address for every BFD packet and scan through the > 127/8 range. Almost all hashing algorithms use the IP-DA for hashing and > therefore eventually all paths (component links) will be exercised. > > However, that wouldn't work when the encapsulation is IP-only, i.e.: PE <-> > CE (IPVPN) or ASBR <-> ASBR. > > Yes, that is correct since 127/8 is not a valid IP address on the link. > However I am not sure why one would need to quickly detect a component link > down in case of IP routing, since the router won't be able to reroute the > packet anyway. > > Thanks > Shahram > > -shane > > > > Thanks > > Shahram > > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Shane Amante > > Sent: Wednesday, May 11, 2011 7:33 AM > > To: Jeffrey Haas > > Cc: rtg-bfd@ietf.org > > Subject: Re: Time for a recharter > > > > Jeff, All, > > > > I'd like to see if there's interest among WG members to take a look at > [more thoroughly] specifying how BFD may be used to detect availability of > component-links that comprise a LAG or ECMP. > > > > The problems I currently face are: > > a) "Standalone" BFD Asynchronous Mode, the most widely implemented form > of BFD as far as I've seen, will establish a single Control session that has > the same UDP/IP 5-tuple for the life of that particular BFD session. > Unfortunately, the packets from that BFD session will get forwarded down > only a single component-link of the LAG and/or ECMP path, due to the nature > of the stateless load-distribution hash algorithm employed at forwarding > time of the BFD packet. With a large number of component-links in a single > LAG and/or ECMP, this results in not monitoring a significant number of > potential forwarding paths. > > b) In theory, LACP is already used for this (if/when the component-links > are Ethernet); however, the fast periodic timer for LACPDU's is 1 second > with a 3-second timeout. Hardly sub-second detection. > > c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM > (Continuity Check Messages), which are specified to detect physical link > failures sub-second, the configuration of either of these protocols is > massively complex and onerous, (think: several lines of configuration and > associated variables per physical, component-link interface and then > multiply that by the number of component-link interfaces in a single LAG). > It's also worth noting that the 'learning curve' for either of those > protocols is fairly steep, while most IP/MPLS shops are already familiar > with and have been using BFD for several years already. > > > > In the "nice to have" category: > > d) LACP is only designed to work over a set of component-links whose > physical port speeds are identical, (e.g.: all 10 GbE in a single LAG). It > may be useful to have a monitoring protocol that was able to check > availability if/when there are different physical link speeds inside the > same LAG group, e.g.: N x 100 GbE + M x 10 GbE. > > > > For now, I'll stop short of suggesting some potential ways that BFD might > be extended to support monitoring of component-links in a LAG and/or ECMP to > first see if there's interest by others in considering taking on this work. > Assuming there is I would be happy to suggest appropriate scope and > milestones of that work. > > > > Thanks, > > > > -shane > > > > > > > > On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: > >> Working Group, > >> > >> As our ADs have reminded us, we're in need of a re-charter for the > >> working group. Based on the minutes from our last session and some > items > >> the chairs have been approached about, please find a possible draft > charter > >> for discussion. Note that milestones have yet to be determined. > >> > >> Commentary on the draft charter's work items: > >> - The MIB work is a lingering work item from our prior charter. The > current > >> status is that it's ready for last call but we'd like to hold off on > doing > >> that until the MPLS-TP work with relation to > draft-ietf-mpls-tp-cc-cv-rdi > >> has converged to final nits. IMO, we're very close on that. > >> (This chair would be thrilled to have that work complete prior to the > >> completion of our re-charter.) > >> > >> - We continue to provide a stewardship role for the BFD core protocol. > As > >> such, we'll be assisting other working groups with the use of BFD in > their > >> applications. This covers several of the items in the draft charter > >> including DHCP, MPLS-TP and TRILL. > >> > >> - The cryptographic work was presented at our last session. We had > >> reasonable consensus about adopting this as a working group item even if > >> there was some contention on the details. As part of this re-chartering > >> we would be formally be requesting this to be adopted as a WG item. > >> > >> - The P2MP work was deferred from the original charter until the base > BFD > >> protocol was solidified. > >> > >> Send your comments on the draft charter to the mailing list. Please > >> annotate your comments specifically with whether this is an edit to the > >> charter text or a suggested addition or deletion for working group > items. > >> > >> -- Jeff > >> > > > > > > > > > > --0016e6db295a6ad73b04a303e986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shahram,
=A0
I see 2 issues:
=A0
1. As you mentioned "almost" all paths will be exercised (ba= sed on IP-DA).
2. We are running the OAM at a higher layer, which could mean that som= e failures may be triggered even when there is no failure in LAG.=A0Also no= te not all LAG's are Layer-3 and may not be using IP in the data plane.=
=A0
Thanks,
Vishwas

On Wed, May 11, 2011 at 10:54 AM, Shahram Davari= <davari@broadc= om.com> wrote:
Hi Shane,

-----Original Message-----
From: Shane Amante [mai= lto:shane@castlepoint.net]
= Sent: Wednesday, May 11, 2011 10:48 AM
To: Shahram Davari
Cc: Jeffrey= Haas; rtg-bfd@ietf.org
Subject: Re: Time for a recharter

Hi Shahram,

On May 11, 2011, at 11:12 AM, Shahram = Davari wrote:
> Hi Shane,
>
> In case of Single-HOP BFD o= ne could use the 127/8 IP address and scan the address range to exercise th= e other component links similar to LSP-Ping. Wouldn't that solve the pr= oblem?

A similar suggestion was provided off-list to me by John Drake.

= If there was MPLS encapsulation on the link that would work, (although I= 9;m not sure the details of feeding the discovery of the component-links fr= om something like LSP-ping to BFD are [adequately] specified, but perhaps I= 'm misinformed?).

SD> This won't require any input from LSP-Ping. The proced= ure would be to change the Destination IP address for every BFD packet and = scan through the 127/8 range. Almost all hashing algorithms use the IP-DA f= or hashing and therefore eventually all paths (component links) will be exe= rcised.

However, that wouldn't work when the encapsulatio= n is IP-only, i.e.: PE <-> CE (IPVPN) or ASBR <-> ASBR.

=
Yes, that is correct since 127/8 is not a valid IP address on the lin= k. However I am not sure why one would need to quickly detect a component l= ink down in case of IP routing, since the router won't be able to rerou= te the packet anyway.

Thanks
Shahram

-shane


> Thanks
> Shahram
>=
> -----Original Message-----
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Shane A= mante
> Sent: Wednesday, May 11, 2011 7:33 AM
> To: Jeffrey Haas
>= Cc: rtg-bfd@ietf.org
> Subje= ct: Re: Time for a recharter
>
> Jeff, All,
>
> I&#= 39;d like to see if there's interest among WG members to take a look at= [more thoroughly] specifying how BFD may be used to detect availability of= component-links that comprise a LAG or ECMP.
>
> The problems I currently face are:
> a) =A0"Standal= one" BFD Asynchronous Mode, the most widely implemented form of BFD as= far as I've seen, will establish a single Control session that has the= same UDP/IP 5-tuple for the life of that particular BFD session. =A0Unfort= unately, the packets from that BFD session will get forwarded down only a s= ingle component-link of the LAG and/or ECMP path, due to the nature of the = stateless load-distribution hash algorithm employed at forwarding time of t= he BFD packet. =A0With a large number of component-links in a single LAG an= d/or ECMP, this results in not monitoring a significant number of potential= forwarding paths.
> b) =A0In theory, LACP is already used for this (if/when the component-= links are Ethernet); however, the fast periodic timer for LACPDU's is 1= second with a 3-second timeout. =A0Hardly sub-second detection.
> c)= =A0While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM (Continu= ity Check Messages), which are specified to detect physical link failures s= ub-second, the configuration of either of these protocols is massively comp= lex and onerous, (think: several lines of configuration and associated vari= ables per physical, component-link interface and then multiply that by the = number of component-link interfaces in a single LAG). =A0It's also wort= h noting that the 'learning curve' for either of those protocols is= fairly steep, while most IP/MPLS shops are already familiar with and have = been using BFD for several years already.
>
> In the "nice to have" category:
> d) =A0LACP i= s only designed to work over a set of component-links whose physical port s= peeds are identical, (e.g.: all 10 GbE in a single LAG). =A0It may be usefu= l to have a monitoring protocol that was able to check availability if/when= there are different physical link speeds inside the same LAG group, e.g.: = N x 100 GbE + M x 10 GbE.
>
> For now, I'll stop short of suggesting some potential ways= that BFD might be extended to support monitoring of component-links in a L= AG and/or ECMP to first see if there's interest by others in considerin= g taking on this work. =A0Assuming there is I would be happy to suggest app= ropriate scope and milestones of that work.
>
> Thanks,
>
> -shane
>
>
>
>= On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote:
>> Working Group,=
>>
>> As our ADs have reminded us, we're in need of = a re-charter for the
>> working group. =A0Based on the minutes from our last session and s= ome items
>> the chairs have been approached about, please find a = possible draft charter
>> for discussion. =A0Note that milestones = have yet to be determined.
>>
>> Commentary on the draft charter's work items:
&= gt;> - The MIB work is a lingering work item from our prior charter. =A0= The current
>> status is that it's ready for last call but we&= #39;d like to hold off on doing
>> that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc= -cv-rdi
>> has converged to final nits. =A0IMO, we're very clo= se on that.
>> (This chair would be thrilled to have that work com= plete prior to the
>> completion of our re-charter.)
>>
>> - We contin= ue to provide a stewardship role for the BFD core protocol. =A0As
>&g= t; such, we'll be assisting other working groups with the use of BFD in= their
>> applications. =A0This covers several of the items in the draft cha= rter
>> including DHCP, MPLS-TP and TRILL.
>>
>>= - The cryptographic work was presented at our last session. =A0We had
&= gt;> reasonable consensus about adopting this as a working group item ev= en if
>> there was some contention on the details. =A0As part of this re-ch= artering
>> we would be formally be requesting this to be adopted = as a WG item.
>>
>> - The P2MP work was deferred from the= original charter until the base BFD
>> protocol was solidified.
>>
>> Send your comment= s on the draft charter to the mailing list. =A0Please
>> annotate = your comments specifically with whether this is an edit to the
>> = charter text or a suggested addition or deletion for working group items. >>
>> -- Jeff
>> <bfd-charter.txt>
>>
>




--0016e6db295a6ad73b04a303e986-- From shane@castlepoint.net Wed May 11 11:19:37 2011 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 81111E07F5 for ; Wed, 11 May 2011 11:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU+OAnQTLhnO for ; Wed, 11 May 2011 11:19:36 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 838E1E06F5 for ; Wed, 11 May 2011 11:19:36 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 312FC268037; Wed, 11 May 2011 12:19:36 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 11 May 2011 12:19:36 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56100; data-bytes=0 Subject: Re: Time for a recharter Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD695A5C7344C@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 11 May 2011 12:19:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <67070BC9-5244-45CE-BCE5-0220BCA53403@castlepoint.net> References: <20110507133545.GB17459@slice> <2C2F1EBA8050E74EA81502D5740B4BD695A5C733FB@SJEXCHCCR02.corp.ad.broadcom.com> <0ADCE0A9-3BE7-4779-81C0-227FC79B1AC9@castlepoint.net> <2C2F1EBA8050E74EA81502D5740B4BD695A5C7344C@SJEXCHCCR02.corp.ad.broadcom.com> To: Shahram Davari 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: Wed, 11 May 2011 18:19:37 -0000 Hi Shahram, On May 11, 2011, at 11:54 AM, Shahram Davari wrote: > Hi Shane, >=20 > -----Original Message----- > From: Shane Amante [mailto:shane@castlepoint.net]=20 > Sent: Wednesday, May 11, 2011 10:48 AM > To: Shahram Davari > Cc: Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: Time for a recharter >=20 > Hi Shahram, >=20 > On May 11, 2011, at 11:12 AM, Shahram Davari wrote: >> Hi Shane, >>=20 >> In case of Single-HOP BFD one could use the 127/8 IP address and scan = the address range to exercise the other component links similar to = LSP-Ping. Wouldn't that solve the problem? >=20 > A similar suggestion was provided off-list to me by John Drake. >=20 > If there was MPLS encapsulation on the link that would work, (although = I'm not sure the details of feeding the discovery of the component-links = from something like LSP-ping to BFD are [adequately] specified, but = perhaps I'm misinformed?). >=20 > SD> This won't require any input from LSP-Ping. The procedure would be = to change the Destination IP address for every BFD packet and scan = through the 127/8 range. Almost all hashing algorithms use the IP-DA for = hashing and therefore eventually all paths (component links) will be = exercised. OK. There are likely other approaches to solving the aforementioned use = case, as well, but presumably we'd get to those if/when the WG agreed = there was sufficient interest to add this to the charter ... which is = what I'm trying to focus on, for now. :) Are you supportive of adding = this to the new charter? > However, that wouldn't work when the encapsulation is IP-only, i.e.: = PE <-> CE (IPVPN) or ASBR <-> ASBR. >=20 > Yes, that is correct since 127/8 is not a valid IP address on the = link. However I am not sure why one would need to quickly detect a = component link down in case of IP routing, since the router won't be = able to reroute the packet anyway. A few things to keep in mind: 1) IPFRR could be used to [quickly] reroute the packet; and, 2) One may want to use BFD to quickly detect failure on a [single] = "bad" component-link and remove it from the LAG group, while still = keeping the LAG operational and still forwarding packets across the = remaining "good" component-links. This is similar to how = 'minimum-links' works in various LAG implementations today, (where an = operator may set minimum-links to N-1, N-2, etc. to achieve this = behavior). In theory, this same mechanism could also be used to trigger = a CSPF to recalculate a new best path for MPLS LSP's that ride over this = LAG, because there is insufficient BW to adequately carry all the = traffic on the LAG. In summary, BFD would be used for detection of a = forwarding fault on one or more component-links, but the resulting = 'action' could be one of either: a) Tearing down the whole LAG or removing a 'path' from the ECMP = group; or, b) Leave the LAG and/or ECMP up/operational, in a 'degraded' state, = and continue IP or MPLS forwarding across it, i.e.: no re-route would = occur. Thanks, -shane > Thanks > Shahram=20 >=20 > -shane >=20 >=20 >> Thanks >> Shahram >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Shane Amante >> Sent: Wednesday, May 11, 2011 7:33 AM >> To: Jeffrey Haas >> Cc: rtg-bfd@ietf.org >> Subject: Re: Time for a recharter >>=20 >> Jeff, All, >>=20 >> I'd like to see if there's interest among WG members to take a look = at [more thoroughly] specifying how BFD may be used to detect = availability of component-links that comprise a LAG or ECMP. >>=20 >> The problems I currently face are: >> a) "Standalone" BFD Asynchronous Mode, the most widely implemented = form of BFD as far as I've seen, will establish a single Control session = that has the same UDP/IP 5-tuple for the life of that particular BFD = session. Unfortunately, the packets from that BFD session will get = forwarded down only a single component-link of the LAG and/or ECMP path, = due to the nature of the stateless load-distribution hash algorithm = employed at forwarding time of the BFD packet. With a large number of = component-links in a single LAG and/or ECMP, this results in not = monitoring a significant number of potential forwarding paths. >> b) In theory, LACP is already used for this (if/when the = component-links are Ethernet); however, the fast periodic timer for = LACPDU's is 1 second with a 3-second timeout. Hardly sub-second = detection. >> c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM = (Continuity Check Messages), which are specified to detect physical link = failures sub-second, the configuration of either of these protocols is = massively complex and onerous, (think: several lines of configuration = and associated variables per physical, component-link interface and then = multiply that by the number of component-link interfaces in a single = LAG). It's also worth noting that the 'learning curve' for either of = those protocols is fairly steep, while most IP/MPLS shops are already = familiar with and have been using BFD for several years already. >>=20 >> In the "nice to have" category: >> d) LACP is only designed to work over a set of component-links whose = physical port speeds are identical, (e.g.: all 10 GbE in a single LAG). = It may be useful to have a monitoring protocol that was able to check = availability if/when there are different physical link speeds inside the = same LAG group, e.g.: N x 100 GbE + M x 10 GbE. >>=20 >> For now, I'll stop short of suggesting some potential ways that BFD = might be extended to support monitoring of component-links in a LAG = and/or ECMP to first see if there's interest by others in considering = taking on this work. Assuming there is I would be happy to suggest = appropriate scope and milestones of that work. >>=20 >> Thanks, >>=20 >> -shane >>=20 >>=20 >>=20 >> On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: >>> Working Group, >>>=20 >>> As our ADs have reminded us, we're in need of a re-charter for the >>> working group. Based on the minutes from our last session and some = items >>> the chairs have been approached about, please find a possible draft = charter >>> for discussion. Note that milestones have yet to be determined. >>>=20 >>> Commentary on the draft charter's work items: >>> - The MIB work is a lingering work item from our prior charter. The = current >>> status is that it's ready for last call but we'd like to hold off on = doing >>> that until the MPLS-TP work with relation to = draft-ietf-mpls-tp-cc-cv-rdi >>> has converged to final nits. IMO, we're very close on that. >>> (This chair would be thrilled to have that work complete prior to = the >>> completion of our re-charter.) >>>=20 >>> - We continue to provide a stewardship role for the BFD core = protocol. As >>> such, we'll be assisting other working groups with the use of BFD in = their >>> applications. This covers several of the items in the draft charter >>> including DHCP, MPLS-TP and TRILL. >>>=20 >>> - The cryptographic work was presented at our last session. We had >>> reasonable consensus about adopting this as a working group item = even if >>> there was some contention on the details. As part of this = re-chartering >>> we would be formally be requesting this to be adopted as a WG item. >>>=20 >>> - The P2MP work was deferred from the original charter until the = base BFD >>> protocol was solidified. >>>=20 >>> Send your comments on the draft charter to the mailing list. Please=20= >>> annotate your comments specifically with whether this is an edit to = the >>> charter text or a suggested addition or deletion for working group = items. >>>=20 >>> -- Jeff >>> >>=20 >>=20 >>=20 >=20 >=20 >=20 From mach.chen@huawei.com Wed May 11 18:31:34 2011 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 39731E08A4 for ; Wed, 11 May 2011 18:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beV2uaQTNusL for ; Wed, 11 May 2011 18:31:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id F3D0FE0873 for ; Wed, 11 May 2011 18:31:32 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL2009686WH86@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 12 May 2011 09:31:29 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200EYF6WHYH@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 12 May 2011 09:31:29 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 12 May 2011 09:31:24 +0800 Received: from SZXEML502-MBX.china.huawei.com ([169.254.6.52]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 12 May 2011 09:31:29 +0800 Date: Thu, 12 May 2011 01:31:28 +0000 From: Mach Chen Subject: RE: Time for a recharter In-reply-to: X-Originating-IP: [10.110.98.39] To: Shane Amante , Jeffrey Haas Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Time for a recharter Thread-index: AQHMDL5Zj6BMtgpN20GDxGNBRCCbApSHMPsAgAE7qVA= X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: C6q5 Eztc FebJ GFmb GiU7 IbBG J/Th NXkB Nh7S Q3pt WZPY WdwP WgLq Zb80 b9U+ eECT; 3; agBoAGEAYQBzAEAAcABmAHIAYwAuAG8AcgBnADsAcgB0AGcALQBiAGYAZABAAGkAZQB0AGYALgBvAHIAZwA7AHMAaABhAG4AZQBAAGMAYQBzAHQAbABlAHAAbwBpAG4AdAAuAG4AZQB0AA==; Sosha1_v1; 7; {093DDB29-7778-4A38-84BE-67F2BEBED49D}; bQBhAGMAaAAuAGMAaABlAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 12 May 2011 01:31:22 GMT;UgBFADoAIABUAGkAbQBlACAAZgBvAHIAIABhACAAcgBlAGMAaABhAHIAdABlAHIA x-cr-puzzleid: {093DDB29-7778-4A38-84BE-67F2BEBED49D} References: <20110507133545.GB17459@slice> X-Mailman-Approved-At: Sat, 14 May 2011 12:16:44 -0700 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 01:31:34 -0000 Hi Shane, Thanks for pointed out this! I agree with you that we may need to extend BFD to detect the failure of one/some/all links belonging to a LAG/bundle interface, and I also have seen similar requirements from some service providers. The requirements/scenarios are that BFD is required to run directly on the interfaces and associating the BFD session status with the status of the interfaces, thus consequently taking down or bringing up the interfaces rapidly by BFD One example of this is LAG/Bundle interface which is consisted of multiple component interfaces, it requires to detect the status of each component interface hence to block the fault interfaces when forwarding packets, or take down the trunk/bundle interface when the number/bandwidth of fault component interfaces reaches a preconfigured threshold. And actually we have a rough draft (interface BFD) about this which was written several months ago. Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Shane Amante > Sent: Wednesday, May 11, 2011 10:33 PM > To: Jeffrey Haas > Cc: rtg-bfd@ietf.org > Subject: Re: Time for a recharter > > Jeff, All, > > I'd like to see if there's interest among WG members to take a look at [more > thoroughly] specifying how BFD may be used to detect availability of > component-links that comprise a LAG or ECMP. > > The problems I currently face are: > a) "Standalone" BFD Asynchronous Mode, the most widely implemented form > of BFD as far as I've seen, will establish a single Control session that has the > same UDP/IP 5-tuple for the life of that particular BFD session. Unfortunately, > the packets from that BFD session will get forwarded down only a single > component-link of the LAG and/or ECMP path, due to the nature of the > stateless load-distribution hash algorithm employed at forwarding time of the > BFD packet. With a large number of component-links in a single LAG and/or > ECMP, this results in not monitoring a significant number of potential > forwarding paths. > b) In theory, LACP is already used for this (if/when the component-links are > Ethernet); however, the fast periodic timer for LACPDU's is 1 second with a > 3-second timeout. Hardly sub-second detection. > c) While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM (Continuity > Check Messages), which are specified to detect physical link failures > sub-second, the configuration of either of these protocols is massively complex > and onerous, (think: several lines of configuration and associated variables per > physical, component-link interface and then multiply that by the number of > component-link interfaces in a single LAG). It's also worth noting that the > 'learning curve' for either of those protocols is fairly steep, while most IP/MPLS > shops are already familiar with and have been using BFD for several years > already. > > In the "nice to have" category: > d) LACP is only designed to work over a set of component-links whose physical > port speeds are identical, (e.g.: all 10 GbE in a single LAG). It may be useful to > have a monitoring protocol that was able to check availability if/when there are > different physical link speeds inside the same LAG group, e.g.: N x 100 GbE + M > x 10 GbE. > > For now, I'll stop short of suggesting some potential ways that BFD might be > extended to support monitoring of component-links in a LAG and/or ECMP to > first see if there's interest by others in considering taking on this work. > Assuming there is I would be happy to suggest appropriate scope and > milestones of that work. > > Thanks, > > -shane > > > > On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote: > > Working Group, > > > > As our ADs have reminded us, we're in need of a re-charter for the > > working group. Based on the minutes from our last session and some items > > the chairs have been approached about, please find a possible draft charter > > for discussion. Note that milestones have yet to be determined. > > > > Commentary on the draft charter's work items: > > - The MIB work is a lingering work item from our prior charter. The current > > status is that it's ready for last call but we'd like to hold off on doing > > that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-rdi > > has converged to final nits. IMO, we're very close on that. > > (This chair would be thrilled to have that work complete prior to the > > completion of our re-charter.) > > > > - We continue to provide a stewardship role for the BFD core protocol. As > > such, we'll be assisting other working groups with the use of BFD in their > > applications. This covers several of the items in the draft charter > > including DHCP, MPLS-TP and TRILL. > > > > - The cryptographic work was presented at our last session. We had > > reasonable consensus about adopting this as a working group item even if > > there was some contention on the details. As part of this re-chartering > > we would be formally be requesting this to be adopted as a WG item. > > > > - The P2MP work was deferred from the original charter until the base BFD > > protocol was solidified. > > > > Send your comments on the draft charter to the mailing list. Please > > annotate your comments specifically with whether this is an edit to the > > charter text or a suggested addition or deletion for working group items. > > > > -- Jeff > >