From marc@sniff.de Sat Dec 10 12:20:33 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 71C4721F8B51 for ; Sat, 10 Dec 2011 12:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ30aVSFYQMl for ; Sat, 10 Dec 2011 12:20:32 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2621F8B50 for ; Sat, 10 Dec 2011 12:20:32 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 2EC242AA0F for ; Sat, 10 Dec 2011 20:20:30 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Any relation to BFD? (was: I-D Action: draft-li-bfd-somfdl-00.txt) From: Marc Binderberger In-Reply-To: <20110914091931.27054.94887.idtracker@ietfa.amsl.com> Date: Sat, 10 Dec 2011 21:20:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BBB5ACA-10FD-4D70-BA13-0FAAD4057076@sniff.de> References: <20110914091931.27054.94887.idtracker@ietfa.amsl.com> To: rtg-bfd@ietf.org X-Mailer: Apple Mail (2.1084) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 20:20:33 -0000 Hello to the BFD community, the below draft, why is this in the BFD area? While the topic of "fast detection" fits I see references to BFD only in = the Introduction and the security considerations sections, and there in = a fairly generic way. Maybe I'm missing the obvious and how does this draft relate to the BFD = protocol? Regards, Marc On 2011-09-14, at 11:19 , Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Service-Oriented Mechanism for Fault Detection = and Localization > Author(s) : Li Yiwei > Zhao Jihong > Wang Li > Filename : draft-li-bfd-somfdl-00.txt > Pages : 13 > Date : 2011-09-14 >=20 > This document describes a Service-Oriented Mechanism for Fault > Detection and Localization (SOMFDL). This mechanism brings up the > concepts of "Chord supplementary" and "QoS = Trigger". By monitoring > the real-time QoS level of the forward path, network can launch the > mechanism when the QoS level cannot satisfy the requirement of > service transmission, so that fault detection and localization can = be > realized. By designing related protocols, the manipuility of this > mechanism can be guaranteed. Utilizing this mechanism, network can > accomplish fault detection and localization in a time scale of > milliseconds with a few datagram sent. >=20 >=20 >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-li-bfd-somfdl-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-li-bfd-somfdl-00.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Marc Binderberger From manav.bhatia@alcatel-lucent.com Tue Dec 13 10:21:35 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 E401821F8ABD for ; Tue, 13 Dec 2011 10:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msOBLTMKmP7H for ; Tue, 13 Dec 2011 10:21:34 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id ABEB021F8AA8 for ; Tue, 13 Dec 2011 10:21:33 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBDILT3I000509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Dec 2011 12:21:32 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBDILSBJ028486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 13 Dec 2011 23:51:29 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 13 Dec 2011 23:51:28 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Tue, 13 Dec 2011 23:51:27 +0530 Subject: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 18:21:35 -0000 Hi, We had a very lively debate on the BFD mailing list a few months back on st= andardizing BFD over the LAG interfaces. We have written a draft that proposes a new approach that fixes the issues = that are seen with how folks do BFD over the LAGs today. Draft available here: http://tools.ietf.org/id/draft-mmm-bfd-on-lags-00.txt Would be great to comments from the WG. Cheers,=20 Marc, Mach and Manav -- Abstract This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent BFD session on every LAG member link. A dedicated well-known multicast IP address for both IPv4 and IPv6 is introduced as the destination IP address of the BFD packets when running BFD on the member links of the LAG. There is currently no standard that describes how BFD should run on LAG interfaces. As a result multiple non-interoperable BFD implementations for LAG interfaces exist. This draft provides a short overview as a context for the new proposed mechanism.= From jeff.tantsura@ericsson.com Tue Dec 13 12:02:42 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 BE8DF21F88B7 for ; Tue, 13 Dec 2011 12:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuZ3x+TBadpb for ; Tue, 13 Dec 2011 12:02:42 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E64F321F889A for ; Tue, 13 Dec 2011 12:02:37 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBDK2Xps005887; Tue, 13 Dec 2011 14:02:34 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 13 Dec 2011 15:02:27 -0500 From: Jeff Tantsura To: "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Tue, 13 Dec 2011 15:02:25 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C423A77@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 20:02:42 -0000 Hi Manav, IMHO BFD over LAG session type (single vs multi) should be transparent to t= he upper layer protocols. When L3 protocol registers with RIB for BFD status it is not interested in = type of BFD session it is interested in its state. So to keep logic simple from L3 protocol point of view it would be: LAG constituent down && min-links has not been met -> L3 protocol doesn't g= et notified LAG constituent down && min-links has been met -> L3 protocol gets BFD DOWN As for IPv6 I'd suggest to use LL (FF02) as this is for single hop BFD Please keep in mind - we were the first vendor to implement this (5 years a= go) and have had many discussions with our customers on implementation, so = there's quite some experience. =20 P.S. Personally I don't really like "pipes" everywhere, much too ALU :) Regards, Jeff -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) Sent: Tuesday, December 13, 2011 10:21 AM To: rtg-bfd@ietf.org Subject: BFD on LAG interfaces Hi, We had a very lively debate on the BFD mailing list a few months back on st= andardizing BFD over the LAG interfaces. We have written a draft that proposes a new approach that fixes the issues = that are seen with how folks do BFD over the LAGs today. Draft available here: http://tools.ietf.org/id/draft-mmm-bfd-on-lags-00.txt Would be great to comments from the WG. Cheers,=20 Marc, Mach and Manav -- Abstract This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent BFD session on every LAG member link. A dedicated well-known multicast IP address for both IPv4 and IPv6 is introduced as the destination IP address of the BFD packets when running BFD on the member links of the LAG. There is currently no standard that describes how BFD should run on LAG interfaces. As a result multiple non-interoperable BFD implementations for LAG interfaces exist. This draft provides a short overview as a context for the new proposed mechanism. From toms.sanders@gmail.com Tue Dec 13 12:18:17 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 939E821F8AF1 for ; Tue, 13 Dec 2011 12:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN2gEMOWAVNY for ; Tue, 13 Dec 2011 12:18:17 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6AEB21F8AEA for ; Tue, 13 Dec 2011 12:18:16 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so76441wgb.13 for ; Tue, 13 Dec 2011 12:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j4Jbvm/t1CvOx4FAUDRaWLLmz5M8JUKMig4XipKQ0P8=; b=LHcSEK6wOFXwrixgih0I7KtMOJ1RbrFz41SNOD6jMGX56excFLVbQrjQE4eNiUnHDM JP6Hq2Z0JQ6sP4jZIiYuO7JDin9HcPgD65DsvUolb5luG4Wrq5igdyvniq2jdd7HCtbQ 1YTen/EoFCdTprK6+titkMWtgKXXMHD9N/s1Q= MIME-Version: 1.0 Received: by 10.227.208.134 with SMTP id gc6mr20476wbb.3.1323807496025; Tue, 13 Dec 2011 12:18:16 -0800 (PST) Received: by 10.223.86.11 with HTTP; Tue, 13 Dec 2011 12:18:15 -0800 (PST) In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C423A77@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <0ED867EB33AB2B45AAB470D5A64CDBF6181C423A77@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 14 Dec 2011 01:48:15 +0530 Message-ID: Subject: Re: BFD on LAG interfaces From: Tom Sanders To: Jeff Tantsura Content-Type: text/plain; charset=UTF-8 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 20:18:17 -0000 > IMHO BFD over LAG session type (single vs multi) should be transparent to the upper layer protocols. > When L3 protocol registers with RIB for BFD status it is not interested in type of BFD session it is interested in its state. > So to keep logic simple from L3 protocol point of view it would be: > > LAG constituent down && min-links has not been met -> L3 protocol doesn't get notified > LAG constituent down && min-links has been met -> L3 protocol gets BFD DOWN How do you detect that a LAG constituent link is down? LACP? Its this (dependency on LAG which converges in order of seconds) that this draft wishes to avoid. I think its about how fast one can detect each individual LAG member link going down (by running BFD over each link). Toms From jeff.tantsura@ericsson.com Tue Dec 13 14:41: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 DC5F711E80A4 for ; Tue, 13 Dec 2011 14:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65+Plej7xRvu for ; Tue, 13 Dec 2011 14:41:49 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6129B11E809B for ; Tue, 13 Dec 2011 14:41:49 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pBDMfktI024461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Dec 2011 16:41:47 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 13 Dec 2011 17:41:46 -0500 From: Jeff Tantsura To: Tom Sanders Date: Tue, 13 Dec 2011 17:41:44 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy51F1cpKv68ROHRLWcSa9c5+NuNwAE7YFQ Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C48032A@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <0ED867EB33AB2B45AAB470D5A64CDBF6181C423A77@EUSAACMS0701.eamcs.ericsson.se> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 22:41:50 -0000 VG9tLA0KDQpUaGF0J3MgZXhhY3RseSB3aGF0IHdlIGhhdmUgYmVlbiBkb2luZyBmb3IgeWVhcnMs IEJGRCBzZXNzaW9uIHBlciBMQUcgY29uc3RpdHVlbnQuDQoNClJlZ2FyZHMsDQpKZWZmDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRvbSBTYW5kZXJzIFttYWlsdG86dG9t cy5zYW5kZXJzQGdtYWlsLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxMywgMjAxMSAx MjoxOCBQTQ0KVG86IEplZmYgVGFudHN1cmENCkNjOiBydGctYmZkQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogQkZEIG9uIExBRyBpbnRlcmZhY2VzDQoNCj4gSU1ITyBCRkQgb3ZlciBMQUcgc2Vzc2lv biB0eXBlIChzaW5nbGUgdnMgbXVsdGkpIHNob3VsZCBiZSB0cmFuc3BhcmVudCB0byB0aGUgdXBw ZXIgbGF5ZXIgcHJvdG9jb2xzLg0KPiBXaGVuIEwzIHByb3RvY29sIHJlZ2lzdGVycyB3aXRoIFJJ QiBmb3IgQkZEIHN0YXR1cyBpdCBpcyBub3QgaW50ZXJlc3RlZCBpbiB0eXBlIG9mIEJGRCBzZXNz aW9uIGl0IGlzIGludGVyZXN0ZWQgaW4gaXRzIHN0YXRlLg0KPiBTbyB0byBrZWVwIGxvZ2ljIHNp bXBsZSBmcm9tIEwzIHByb3RvY29sIHBvaW50IG9mIHZpZXcgaXQgd291bGQgYmU6DQo+DQo+IExB RyBjb25zdGl0dWVudCBkb3duICYmIG1pbi1saW5rcyBoYXMgbm90IGJlZW4gbWV0IC0+IEwzIHBy b3RvY29sIA0KPiBkb2Vzbid0IGdldCBub3RpZmllZCBMQUcgY29uc3RpdHVlbnQgZG93biAmJiBt aW4tbGlua3MgaGFzIGJlZW4gbWV0IC0+IA0KPiBMMyBwcm90b2NvbCBnZXRzIEJGRCBET1dODQoN CkhvdyBkbyB5b3UgZGV0ZWN0IHRoYXQgYSBMQUcgY29uc3RpdHVlbnQgbGluayBpcyBkb3duPyBM QUNQPyBJdHMgdGhpcyAoZGVwZW5kZW5jeSBvbiBMQUcgd2hpY2ggY29udmVyZ2VzIGluIG9yZGVy IG9mIHNlY29uZHMpIHRoYXQgdGhpcyBkcmFmdCB3aXNoZXMgdG8gYXZvaWQuIEkgdGhpbmsgaXRz IGFib3V0IGhvdyBmYXN0IG9uZSBjYW4gZGV0ZWN0IGVhY2ggaW5kaXZpZHVhbCBMQUcgbWVtYmVy IGxpbmsgZ29pbmcgZG93biAoYnkgcnVubmluZyBCRkQgb3ZlciBlYWNoIGxpbmspLg0KDQpUb21z DQo= From manav.bhatia@alcatel-lucent.com Tue Dec 13 16:18:17 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 73FD621F84C3 for ; Tue, 13 Dec 2011 16:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccc-rMkY4GMT for ; Tue, 13 Dec 2011 16:18:17 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BF64C21F84C5 for ; Tue, 13 Dec 2011 16:18:13 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pBE0I8DZ017415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Dec 2011 18:18:10 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBE0I7QU022604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Dec 2011 05:48:07 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 14 Dec 2011 05:48:07 +0530 From: "Bhatia, Manav (Manav)" To: Jeff Tantsura , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 05:48:05 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F0D4B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <0ED867EB33AB2B45AAB470D5A64CDBF6181C423A77@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C423A77@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 14 Dec 2011 00:18:17 -0000 Hi Jeff, =20 > IMHO BFD over LAG session type (single vs multi) should be=20 > transparent to the upper layer protocols. > When L3 protocol registers with RIB for BFD status it is not=20 > interested in type of BFD session it is interested in its state. > So to keep logic simple from L3 protocol point of view it would be: >=20 > LAG constituent down && min-links has not been met -> L3=20 > protocol doesn't get notified LAG constituent down &&=20 > min-links has been met -> L3 protocol gets BFD DOWN This is precisely what the draft suggests. You run BFD for a LAG and several L3 applications register for it. Each mem= ber link of the LAG runs a BFD session. Sec 3.3 discusses about the conclud= ed state of the BFD session on the LAG. What is relevant for BFD on LAG is = that the concluded state is the overall state of the LAG. If min-links are up then concluded state is UP.=20 L3 applications are notified once the concluded state goes down. >=20 > As for IPv6 I'd suggest to use LL (FF02) as this is for single hop BFD Yes, we should do that. We should have also mentioned that TTL for all IPv4 multicast packets MUST = be 1. Cheers, Manav= From yael@compass-eos.com Wed Dec 14 07:46:25 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 6FD5021F8B7A for ; Wed, 14 Dec 2011 07:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMK7X8weF18g for ; Wed, 14 Dec 2011 07:46:24 -0800 (PST) Received: from mail.cmpsys.com (mail.cmpsys.com [91.212.114.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5843821F8B73 for ; Wed, 14 Dec 2011 07:46:23 -0800 (PST) Received: from mail.cmpsys.com ([192.168.20.5]) by mail ([192.168.20.5]) with mapi; Wed, 14 Dec 2011 17:46:10 +0200 From: Yael Frank Dayan To: "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 17:46:09 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQAsSewQ Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 14 Dec 2011 15:46:25 -0000 Hi, Wouldn't the correct protocol be a version of BFD that runs over Ethernet? How is IP relevant to a LAG member? Thanks, Yael -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) Sent: Tuesday, December 13, 2011 8:21 PM To: rtg-bfd@ietf.org Subject: BFD on LAG interfaces Hi, We had a very lively debate on the BFD mailing list a few months back on st= andardizing BFD over the LAG interfaces. We have written a draft that proposes a new approach that fixes the issues = that are seen with how folks do BFD over the LAGs today. Draft available here: http://tools.ietf.org/id/draft-mmm-bfd-on-lags-00.txt Would be great to comments from the WG. Cheers,=20 Marc, Mach and Manav -- Abstract This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent BFD session on every LAG member link. A dedicated well-known multicast IP address for both IPv4 and IPv6 is introduced as the destination IP address of the BFD packets when running BFD on the member links of the LAG. There is currently no standard that describes how BFD should run on LAG interfaces. As a result multiple non-interoperable BFD implementations for LAG interfaces exist. This draft provides a short overview as a context for the new proposed mechanism. From toms.sanders@gmail.com Wed Dec 14 08:14:11 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 40C8121F8C06 for ; Wed, 14 Dec 2011 08:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyXD2ExmAKmy for ; Wed, 14 Dec 2011 08:14:10 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B69DD21F8ACA for ; Wed, 14 Dec 2011 08:14:08 -0800 (PST) Received: by faas1 with SMTP id s1so1558773faa.31 for ; Wed, 14 Dec 2011 08:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yvAwQs5YbJBsc56bKExf71i2oA7+z2kUCZKg7IhrKlA=; b=pJ63duyTfndmHBhbpXwihm29c5cYwhKpdUzVY1mQG2fLBCFePndcf6e6vppAIXJ1ti yh97HAMDDDp8ohJi7ZHk+mZigwMev51piDRSFDUN5r062liqL0kiZ6k8w69iBEW7cL8j xwwYp+YDdd5eWgD176rb49z1hGtAJr5us91kc= MIME-Version: 1.0 Received: by 10.180.92.234 with SMTP id cp10mr6013536wib.28.1323879247808; Wed, 14 Dec 2011 08:14:07 -0800 (PST) Received: by 10.223.86.11 with HTTP; Wed, 14 Dec 2011 08:14:06 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 14 Dec 2011 21:44:06 +0530 Message-ID: Subject: Re: BFD on LAG interfaces From: Tom Sanders To: Yael Frank Dayan Content-Type: text/plain; charset=UTF-8 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, 14 Dec 2011 16:14:11 -0000 Yael, There is no BFD that runs directly over ethernet. I think one of the ideas behind the draft is to reuse as much of the existing BFD code as possible. Just treating a constituent link of a LAG as a regular physical port and running BFD on top of it looks really simple to me. This can also easily be extended to work on ASICs that are designed to do BFD in HW. Why complicate this with another encapsulation and such? Toms On 14 December 2011 21:16, Yael Frank Dayan wrote: > Hi, > Wouldn't the correct protocol be a version of BFD that runs over Ethernet= ? > How is IP relevant to a LAG member? > > Thanks, > Yael > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Bhatia, Manav (Manav) > Sent: Tuesday, December 13, 2011 8:21 PM > To: rtg-bfd@ietf.org > Subject: BFD on LAG interfaces > > Hi, > > We had a very lively debate on the BFD mailing list a few months back on = standardizing BFD over the LAG interfaces. > > We have written a draft that proposes a new approach that fixes the issue= s that are seen with how folks do BFD over the LAGs today. > > Draft available here: > http://tools.ietf.org/id/draft-mmm-bfd-on-lags-00.txt > > Would be great to comments from the WG. > > Cheers, > Marc, Mach and Manav > > -- > > Abstract > > =C2=A0 This document proposes a mechanism to run BFD on Link Aggregation > =C2=A0 Group (LAG) interfaces. =C2=A0It does so by running an independent= BFD > =C2=A0 session on every LAG member link. > > =C2=A0 A dedicated well-known multicast IP address for both IPv4 and IPv6= is > =C2=A0 introduced as the destination IP address of the BFD packets when > =C2=A0 running BFD on the member links of the LAG. > > =C2=A0 There is currently no standard that describes how BFD should run o= n > =C2=A0 LAG interfaces. =C2=A0As a result multiple non-interoperable BFD > =C2=A0 implementations for LAG interfaces exist. =C2=A0This draft provide= s a > =C2=A0 short overview as a context for the new proposed mechanism. --=20 Toms. From nitinb@juniper.net Wed Dec 14 08:25:12 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 AA48B21F8C17 for ; Wed, 14 Dec 2011 08:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe4umjZ93Ca1 for ; Wed, 14 Dec 2011 08:25:11 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BD62621F8C11 for ; Wed, 14 Dec 2011 08:25:10 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTujN4odKi7UsJvshNqEacIEsM6EzJxZS@postini.com; Wed, 14 Dec 2011 08:25:10 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 14 Dec 2011 08:24:25 -0800 From: Nitin Bahadur To: "Bhatia, Manav (Manav)" , Jeff Tantsura , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 08:24:23 -0800 Subject: Re: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nAAIeguvw== Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F0D4B@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 14 Dec 2011 16:25:12 -0000 I read through the draft and I personally do not like the idea of using a r= eserved mcast address.....since it masks one of the IP addresses used for more strict checking on whether the packet= is indeed intended for the recipient. I would prefer using a different UDP port number and keeping everything the= same. That way IP addr checks can be enforced. And based on the different UDP port, the receiving entity will know that it= needs to take constituent interface into account as well. We have been meaning to write a draft for a long time on this....just been = bogged down with other stuff. Thanks Nitin On 12/13/11 4:18 PM, "Bhatia, Manav (Manav)" wrote: Hi Jeff, > IMHO BFD over LAG session type (single vs multi) should be > transparent to the upper layer protocols. > When L3 protocol registers with RIB for BFD status it is not > interested in type of BFD session it is interested in its state. > So to keep logic simple from L3 protocol point of view it would be: > > LAG constituent down && min-links has not been met -> L3 > protocol doesn't get notified LAG constituent down && > min-links has been met -> L3 protocol gets BFD DOWN This is precisely what the draft suggests. You run BFD for a LAG and several L3 applications register for it. Each mem= ber link of the LAG runs a BFD session. Sec 3.3 discusses about the conclud= ed state of the BFD session on the LAG. What is relevant for BFD on LAG is = that the concluded state is the overall state of the LAG. If min-links are up then concluded state is UP. L3 applications are notified once the concluded state goes down. > > As for IPv6 I'd suggest to use LL (FF02) as this is for single hop BFD Yes, we should do that. We should have also mentioned that TTL for all IPv4 multicast packets MUST = be 1. Cheers, Manav From rrahman@cisco.com Wed Dec 14 08:28:47 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 375FD21F8783 for ; Wed, 14 Dec 2011 08:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq+QLVWx22YH for ; Wed, 14 Dec 2011 08:28:46 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7744421F86EE for ; Wed, 14 Dec 2011 08:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rrahman@cisco.com; l=3408; q=dns/txt; s=iport; t=1323880126; x=1325089726; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=HFKqVXs6FQYMTd5LelK4qhJNZ1zQmU5nru2rBe01fAc=; b=bUJFr5jX8tODL2ZW7eXIvzmn3hGY1U7l0AoDNkUjqL3iXwop/zPtCYuY BhyS+KxlCSl/R3186FcfzDiZwrlMZ0MRXVchJxqg57RHaYQArlzMVVsia /mWPeVUzU2UjsX48lINSTuLZLxvc5hXLULYp4ECQ2b5z4N9XDyAztUMl/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AABPO6E6tJV2b/2dsb2JhbABDhQiVWY8qgRyBBYFyAQEBBBIBEA0EOgsMBAIBCBEEAQEBAgIGBhcBAgICAQFECQgBAQQBEggah2CYYQGMW5F7gS+JRDNjBIgynws X-IronPort-AV: E=Sophos;i="4.71,353,1320624000"; d="scan'208";a="43919363" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 14 Dec 2011 16:28:46 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBEGSkdo006719; Wed, 14 Dec 2011 16:28:46 GMT Received: from xmb-rcd-204.cisco.com ([72.163.62.211]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Dec 2011 10:28:45 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: BFD on LAG interfaces Date: Wed, 14 Dec 2011 10:28:12 -0600 Message-ID: <654701C60BCC7C4EBD533B89D72BDFEA06747097@XMB-RCD-204.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: Acy6e22OK1GfEW8HSAWNJyuE9sWYkwAAa40A References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Reshad Rahman (rrahman)" To: "Tom Sanders" , "Yael Frank Dayan" X-OriginalArrivalTime: 14 Dec 2011 16:28:45.0967 (UTC) FILETIME=[739429F0:01CCBA7D] 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, 14 Dec 2011 16:28:47 -0000 SSB0aGluayB0aGUgY29uY2VybiBiZWluZyByYWlzZWQgaXMgbGF5ZXJpbmcgdmlvbGF0aW9uLiBU aGVvcmV0aWNhbGx5IHlvdSBjb3VsZCBoYXZlIElQdjQgbm90IHdvcmtpbmcgb24gYSBjb25zdGl0 dWVudCBsaW5rIGJ1dCBvdGhlciB0eXBlIG9mIHRyYWZmaWMgd291bGQgd29yayBmaW5lLg0KDQpS ZWdhcmRzLA0KUmVzaGFkLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRn LWJmZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgVG9tIFNhbmRlcnMNClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTQsIDIw MTEgMTE6MTQgQU0NClRvOiBZYWVsIEZyYW5rIERheWFuDQpDYzogcnRnLWJmZEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IEJGRCBvbiBMQUcgaW50ZXJmYWNlcw0KDQpZYWVsLA0KDQpUaGVyZSBpcyBu byBCRkQgdGhhdCBydW5zIGRpcmVjdGx5IG92ZXIgZXRoZXJuZXQuIEkgdGhpbmsgb25lIG9mIHRo ZQ0KaWRlYXMgYmVoaW5kIHRoZSBkcmFmdCBpcyB0byByZXVzZSBhcyBtdWNoIG9mIHRoZSBleGlz dGluZyBCRkQgY29kZSBhcw0KcG9zc2libGUuIEp1c3QgdHJlYXRpbmcgYSBjb25zdGl0dWVudCBs aW5rIG9mIGEgTEFHIGFzIGEgcmVndWxhcg0KcGh5c2ljYWwgcG9ydCBhbmQgcnVubmluZyBCRkQg b24gdG9wIG9mIGl0IGxvb2tzIHJlYWxseSBzaW1wbGUgdG8gbWUuDQpUaGlzIGNhbiBhbHNvIGVh c2lseSBiZSBleHRlbmRlZCB0byB3b3JrIG9uIEFTSUNzIHRoYXQgYXJlIGRlc2lnbmVkIHRvDQpk byBCRkQgaW4gSFcuDQoNCldoeSBjb21wbGljYXRlIHRoaXMgd2l0aCBhbm90aGVyIGVuY2Fwc3Vs YXRpb24gYW5kIHN1Y2g/DQoNClRvbXMNCg0KT24gMTQgRGVjZW1iZXIgMjAxMSAyMToxNiwgWWFl bCBGcmFuayBEYXlhbiA8eWFlbEBjb21wYXNzLWVvcy5jb20+IHdyb3RlOg0KPiBIaSwNCj4gV291 bGRuJ3QgdGhlIGNvcnJlY3QgcHJvdG9jb2wgYmUgYSB2ZXJzaW9uIG9mIEJGRCB0aGF0IHJ1bnMg b3ZlciBFdGhlcm5ldD8NCj4gSG93IGlzIElQIHJlbGV2YW50IHRvIGEgTEFHIG1lbWJlcj8NCj4N Cj4gVGhhbmtzLA0KPiBZYWVsDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJoYXRpYSwgTWFuYXYgKE1hbmF2KQ0KPiBTZW50OiBUdWVzZGF5LCBE ZWNlbWJlciAxMywgMjAxMSA4OjIxIFBNDQo+IFRvOiBydGctYmZkQGlldGYub3JnDQo+IFN1Ympl Y3Q6IEJGRCBvbiBMQUcgaW50ZXJmYWNlcw0KPg0KPiBIaSwNCj4NCj4gV2UgaGFkIGEgdmVyeSBs aXZlbHkgZGViYXRlIG9uIHRoZSBCRkQgbWFpbGluZyBsaXN0IGEgZmV3IG1vbnRocyBiYWNrIG9u IHN0YW5kYXJkaXppbmcgQkZEIG92ZXIgdGhlIExBRyBpbnRlcmZhY2VzLg0KPg0KPiBXZSBoYXZl IHdyaXR0ZW4gYSBkcmFmdCB0aGF0IHByb3Bvc2VzIGEgbmV3IGFwcHJvYWNoIHRoYXQgZml4ZXMg dGhlIGlzc3VlcyB0aGF0IGFyZSBzZWVuIHdpdGggaG93IGZvbGtzIGRvIEJGRCBvdmVyIHRoZSBM QUdzIHRvZGF5Lg0KPg0KPiBEcmFmdCBhdmFpbGFibGUgaGVyZToNCj4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LW1tbS1iZmQtb24tbGFncy0wMC50eHQNCj4NCj4gV291bGQgYmUgZ3Jl YXQgdG8gY29tbWVudHMgZnJvbSB0aGUgV0cuDQo+DQo+IENoZWVycywNCj4gTWFyYywgTWFjaCBh bmQgTWFuYXYNCj4NCj4gLS0NCj4NCj4gQWJzdHJhY3QNCj4NCj4gwqAgVGhpcyBkb2N1bWVudCBw cm9wb3NlcyBhIG1lY2hhbmlzbSB0byBydW4gQkZEIG9uIExpbmsgQWdncmVnYXRpb24NCj4gwqAg R3JvdXAgKExBRykgaW50ZXJmYWNlcy4gwqBJdCBkb2VzIHNvIGJ5IHJ1bm5pbmcgYW4gaW5kZXBl bmRlbnQgQkZEDQo+IMKgIHNlc3Npb24gb24gZXZlcnkgTEFHIG1lbWJlciBsaW5rLg0KPg0KPiDC oCBBIGRlZGljYXRlZCB3ZWxsLWtub3duIG11bHRpY2FzdCBJUCBhZGRyZXNzIGZvciBib3RoIElQ djQgYW5kIElQdjYgaXMNCj4gwqAgaW50cm9kdWNlZCBhcyB0aGUgZGVzdGluYXRpb24gSVAgYWRk cmVzcyBvZiB0aGUgQkZEIHBhY2tldHMgd2hlbg0KPiDCoCBydW5uaW5nIEJGRCBvbiB0aGUgbWVt YmVyIGxpbmtzIG9mIHRoZSBMQUcuDQo+DQo+IMKgIFRoZXJlIGlzIGN1cnJlbnRseSBubyBzdGFu ZGFyZCB0aGF0IGRlc2NyaWJlcyBob3cgQkZEIHNob3VsZCBydW4gb24NCj4gwqAgTEFHIGludGVy ZmFjZXMuIMKgQXMgYSByZXN1bHQgbXVsdGlwbGUgbm9uLWludGVyb3BlcmFibGUgQkZEDQo+IMKg IGltcGxlbWVudGF0aW9ucyBmb3IgTEFHIGludGVyZmFjZXMgZXhpc3QuIMKgVGhpcyBkcmFmdCBw cm92aWRlcyBhDQo+IMKgIHNob3J0IG92ZXJ2aWV3IGFzIGEgY29udGV4dCBmb3IgdGhlIG5ldyBw cm9wb3NlZCBtZWNoYW5pc20uDQoNCg0KDQotLSANClRvbXMuDQo= From gregory.mirsky@ericsson.com Wed Dec 14 08:40:24 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 A4ED021F8C14 for ; Wed, 14 Dec 2011 08:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGCWNCWN7tcd for ; Wed, 14 Dec 2011 08:40:24 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 14B2921F8BBB for ; Wed, 14 Dec 2011 08:40:24 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pBEGeKRT008290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Dec 2011 10:40:20 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 14 Dec 2011 11:40:19 -0500 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 11:40:17 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQAMnJRQ Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 14 Dec 2011 16:40:24 -0000 Dear Manav, Thank you for forwarding information, otherwise I'd have missed the announc= ement. Please find my comments to the document: - described issues with BFD over LAG seem to be vendor-specific, implementa= tion dependent, i.e. not caused by RFC 5880 and RFC 5881. As result, tag li= ne of Section 2.1 Existing implementations makes generalization to far as i= t seems it is not based on any poll or research but, I assume, only on expe= rience of authors; - any suggestion on relationship between LMM and BFD - implementation speci= fic and doesn't seem to be appropriate in BFD standard; - are you planning to update RFC 5880 and/or RFC 5881 by introducing new BF= D state variable in Section 3.3? - I think that BFD over LAG member links can use 127/8 for IPv4 address fam= ily and 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. Thank you for your kind consideration and I'm looking forward to your feedb= ack. Regards, Greg -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) Sent: Tuesday, December 13, 2011 10:21 AM To: rtg-bfd@ietf.org Subject: BFD on LAG interfaces Hi, We had a very lively debate on the BFD mailing list a few months back on st= andardizing BFD over the LAG interfaces. We have written a draft that proposes a new approach that fixes the issues = that are seen with how folks do BFD over the LAGs today. Draft available here: http://tools.ietf.org/id/draft-mmm-bfd-on-lags-00.txt Would be great to comments from the WG. Cheers, Marc, Mach and Manav -- Abstract This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent BFD session on every LAG member link. A dedicated well-known multicast IP address for both IPv4 and IPv6 is introduced as the destination IP address of the BFD packets when running BFD on the member links of the LAG. There is currently no standard that describes how BFD should run on LAG interfaces. As a result multiple non-interoperable BFD implementations for LAG interfaces exist. This draft provides a short overview as a context for the new proposed mechanism.= From gregory.mirsky@ericsson.com Wed Dec 14 08:43:20 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 1A85A21F86B3 for ; Wed, 14 Dec 2011 08:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAOpICODtDdP for ; Wed, 14 Dec 2011 08:43:19 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9218521F8513 for ; Wed, 14 Dec 2011 08:43:18 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBEGh8qC013218; Wed, 14 Dec 2011 10:43:13 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 14 Dec 2011 11:43:03 -0500 From: Gregory Mirsky To: Tom Sanders , Yael Frank Dayan Date: Wed, 14 Dec 2011 11:43:02 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy6e3cP6fN8UrBoSECrGrSCwh6H9QAA6Q4Q Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 14 Dec 2011 16:43:20 -0000 Hi Tom, I'll note that we have BFD over MPLS with IP encapsulation. IMO, nothing pr= events us from defining BFD over Ethernet with IP encapsulation with much o= f RFC 5885 being of good use. Regards, Greg=20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Tom Sanders Sent: Wednesday, December 14, 2011 8:14 AM To: Yael Frank Dayan Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG interfaces Yael, There is no BFD that runs directly over ethernet. I think one of the ideas = behind the draft is to reuse as much of the existing BFD code as possible. = Just treating a constituent link of a LAG as a regular physical port and ru= nning BFD on top of it looks really simple to me. This can also easily be extended to work on ASICs that are designed to do B= FD in HW. Why complicate this with another encapsulation and such? Toms On 14 December 2011 21:16, Yael Frank Dayan wrote: > Hi, > Wouldn't the correct protocol be a version of BFD that runs over Ethernet= ? > How is IP relevant to a LAG member? > > Thanks, > Yael > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Tuesday, December 13, 2011 8:21 PM > To: rtg-bfd@ietf.org > Subject: BFD on LAG interfaces > > Hi, > > We had a very lively debate on the BFD mailing list a few months back on = standardizing BFD over the LAG interfaces. > > We have written a draft that proposes a new approach that fixes the issue= s that are seen with how folks do BFD over the LAGs today. > > Draft available here: > http://tools.ietf.org/id/draft-mmm-bfd-on-lags-00.txt > > Would be great to comments from the WG. > > Cheers, > Marc, Mach and Manav > > -- > > Abstract > > =A0 This document proposes a mechanism to run BFD on Link Aggregation > =A0 Group (LAG) interfaces. =A0It does so by running an independent BFD > =A0 session on every LAG member link. > > =A0 A dedicated well-known multicast IP address for both IPv4 and IPv6=20 > is > =A0 introduced as the destination IP address of the BFD packets when > =A0 running BFD on the member links of the LAG. > > =A0 There is currently no standard that describes how BFD should run on > =A0 LAG interfaces. =A0As a result multiple non-interoperable BFD > =A0 implementations for LAG interfaces exist. =A0This draft provides a > =A0 short overview as a context for the new proposed mechanism. -- Toms. From manav.bhatia@alcatel-lucent.com Wed Dec 14 09:13: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 AE40521F858C for ; Wed, 14 Dec 2011 09:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPLdEO2mrpUq for ; Wed, 14 Dec 2011 09:13:49 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9AF21F8BBF for ; Wed, 14 Dec 2011 09:13:49 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pBEHDgEv000961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2011 11:13:44 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBEHDeIL018782 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Dec 2011 22:43:41 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 14 Dec 2011 22:43:41 +0530 From: "Bhatia, Manav (Manav)" To: Nitin Bahadur , Jeff Tantsura , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 22:43:39 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nAAIeguvwABXIyg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F0FFC@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D4B@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 14 Dec 2011 17:13:49 -0000 Hi Nitin, > I read through the draft and I personally do not like the=20 > idea of using a reserved mcast address.....since it masks one=20 > of the IP addresses used for more strict checking on whether=20 > the packet is indeed intended for the recipient. We had internally discussed the idea of using a Unicast IP and we felt that= using multicast was better since that avoided the need for L3 to come befo= re a member link of a LAG could be declared operational.=20 Using the IP address of the interface leads into a cyclic loop as you cant = bring up the member links since L3 is not up, and you cant bring up L3 sinc= e the member links are still down. On a point-to-point link isn't the discriminator value good enough to check= if the packet is indeed for the recipient? Cheers, Manav > I would prefer using a different UDP port number and keeping=20 > everything the same. That way IP addr checks can be enforced. > And based on the different UDP port, the receiving entity=20 > will know that it needs to take constituent interface into=20 > account as well. >=20 > We have been meaning to write a draft for a long time on=20 > this....just been bogged down with other stuff. >=20 > Thanks > Nitin >=20 >=20 > On 12/13/11 4:18 PM, "Bhatia, Manav (Manav)"=20 > wrote: >=20 > Hi Jeff, >=20 > > IMHO BFD over LAG session type (single vs multi) should be=20 > transparent=20 > > to the upper layer protocols. > > When L3 protocol registers with RIB for BFD status it is not=20 > > interested in type of BFD session it is interested in its state. > > So to keep logic simple from L3 protocol point of view it would be: > > > > LAG constituent down && min-links has not been met -> L3 protocol=20 > > doesn't get notified LAG constituent down && min-links has=20 > been met ->=20 > > L3 protocol gets BFD DOWN >=20 > This is precisely what the draft suggests. >=20 > You run BFD for a LAG and several L3 applications register=20 > for it. Each member link of the LAG runs a BFD session. Sec=20 > 3.3 discusses about the concluded state of the BFD session on=20 > the LAG. What is relevant for BFD on LAG is that the=20 > concluded state is the overall state of the LAG. >=20 > If min-links are up then concluded state is UP. >=20 > L3 applications are notified once the concluded state goes down. >=20 > > > > As for IPv6 I'd suggest to use LL (FF02) as this is for=20 > single hop BFD >=20 > Yes, we should do that. >=20 > We should have also mentioned that TTL for all IPv4 multicast=20 > packets MUST be 1. >=20 > Cheers, Manav >=20 > = From manav.bhatia@alcatel-lucent.com Wed Dec 14 09:20: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 7AC2C1F0C4F for ; Wed, 14 Dec 2011 09:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjJvvccRJbc1 for ; Wed, 14 Dec 2011 09:20:34 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id EFFB721F8BDB for ; Wed, 14 Dec 2011 09:20:28 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pBEHKK0G006631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2011 11:20:23 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBEHKJTs018918 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Dec 2011 22:50:19 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 14 Dec 2011 22:50:19 +0530 From: "Bhatia, Manav (Manav)" To: Gregory Mirsky , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 22:50:18 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQAMnJRQACNRhQA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 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, 14 Dec 2011 17:20:34 -0000 Hi Greg, > - described issues with BFD over LAG seem to be=20 > vendor-specific, implementation dependent, i.e. not caused by=20 > RFC 5880 and RFC 5881. As result, tag line of Section 2.1=20 > Existing implementations makes generalization to far as it=20 > seems it is not based on any poll or research but, I assume,=20 > only on experience of authors; And what makes you believe that this is an implementation specific issue? Is there a standard on how BFD should work on LAGs? Do you round robin pack= ets, do you send them over one port, what do you do? > - any suggestion on relationship between LMM and BFD -=20 > implementation specific and doesn't seem to be appropriate in=20 > BFD standard; LMM is a generic module name. You can call it whatever you want as long as = you understand what it means.=20 > - are you planning to update RFC 5880 and/or RFC 5881 by=20 > introducing new BFD state variable in Section 3.3? I am not sure if having a concluded state for LAG requires updating 5880/58= 81. An implementation could just overload its internal state to match the s= tate of the LAG. They could work with the existing data structures. Does th= is mean that it does not require updating 5880/5881? I don't know .. > - I think that BFD over LAG member links can use 127/8 for=20 > IPv4 address family and 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. Just trying to understand - how is this better than using a mcast address? = You don't need to reserve an address in this case. Any other benefit? >=20 > Thank you for your kind consideration and I'm looking forward=20 > to your feedback. And you just got it! :) Cheers, Manav From manav.bhatia@alcatel-lucent.com Wed Dec 14 09:28:13 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 2D4861F0C68 for ; Wed, 14 Dec 2011 09:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwoW6CBd6oWs for ; Wed, 14 Dec 2011 09:28:12 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF4E1F0C61 for ; Wed, 14 Dec 2011 09:28:12 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pBEHS2Z1024558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2011 11:28:04 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBEHS1RH019149 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Dec 2011 22:58:01 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 14 Dec 2011 22:58:01 +0530 From: "Bhatia, Manav (Manav)" To: Nitin Bahadur , Jeff Tantsura , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 22:57:59 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nAAIeguvwACE8lQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F1000@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D4B@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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, 14 Dec 2011 17:28:13 -0000 BTW, we also have the other mode defined in Sec 4 which uses BFD over a Big= Pipe mechanism on top of the running BFD over each member link. In that mo= de, BFD runs over each member link to manage the state of the LAG. On top o= f that, we run another BFD session between the two IP end points just like = its done today. So, now the L3 applications really depend upon the second B= FD session and it takes care of the strict checking point that you had brou= ght up and the layering violation issue that somebody else had brought up. In the draft this is an optional mode and implementations SHOULD support it= . Cheers, Manav > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Wednesday, December 14, 2011 9:54 PM > To: Bhatia, Manav (Manav); Jeff Tantsura; rtg-bfd@ietf.org > Subject: Re: BFD on LAG interfaces >=20 >=20 > I read through the draft and I personally do not like the=20 > idea of using a reserved mcast address.....since it masks one=20 > of the IP addresses used for more strict checking on whether=20 > the packet is indeed intended for the recipient. >=20 > I would prefer using a different UDP port number and keeping=20 > everything the same. That way IP addr checks can be enforced. > And based on the different UDP port, the receiving entity=20 > will know that it needs to take constituent interface into=20 > account as well. >=20 > We have been meaning to write a draft for a long time on=20 > this....just been bogged down with other stuff. >=20 > Thanks > Nitin >=20 >=20 > On 12/13/11 4:18 PM, "Bhatia, Manav (Manav)"=20 > wrote: >=20 > Hi Jeff, >=20 > > IMHO BFD over LAG session type (single vs multi) should be=20 > transparent=20 > > to the upper layer protocols. > > When L3 protocol registers with RIB for BFD status it is not=20 > > interested in type of BFD session it is interested in its state. > > So to keep logic simple from L3 protocol point of view it would be: > > > > LAG constituent down && min-links has not been met -> L3 protocol=20 > > doesn't get notified LAG constituent down && min-links has=20 > been met ->=20 > > L3 protocol gets BFD DOWN >=20 > This is precisely what the draft suggests. >=20 > You run BFD for a LAG and several L3 applications register=20 > for it. Each member link of the LAG runs a BFD session. Sec=20 > 3.3 discusses about the concluded state of the BFD session on=20 > the LAG. What is relevant for BFD on LAG is that the=20 > concluded state is the overall state of the LAG. >=20 > If min-links are up then concluded state is UP. >=20 > L3 applications are notified once the concluded state goes down. >=20 > > > > As for IPv6 I'd suggest to use LL (FF02) as this is for=20 > single hop BFD >=20 > Yes, we should do that. >=20 > We should have also mentioned that TTL for all IPv4 multicast=20 > packets MUST be 1. >=20 > Cheers, Manav >=20 > = From gregory.mirsky@ericsson.com Wed Dec 14 09:54:23 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 59CBD21F8B9C for ; Wed, 14 Dec 2011 09:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHhKSITHdm5A for ; Wed, 14 Dec 2011 09:54:22 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB7AE21F8B9B for ; Wed, 14 Dec 2011 09:54:22 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pBEHsGL1015773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Dec 2011 11:54:17 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 14 Dec 2011 12:54:17 -0500 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 12:54:16 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQAMnJRQACNRhQAAAQqBYA== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 14 Dec 2011 17:54:23 -0000 Hi Manav, Thank you for your most expedient response. Please find my notes in-lined t= agged by GIM>> Regards, Greg=20 -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Wednesday, December 14, 2011 9:20 AM To: Gregory Mirsky; rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Hi Greg, > - described issues with BFD over LAG seem to be vendor-specific,=20 > implementation dependent, i.e. not caused by RFC 5880 and RFC 5881. As=20 > result, tag line of Section 2.1 Existing implementations makes=20 > generalization to far as it seems it is not based on any poll or=20 > research but, I assume, only on experience of authors; And what makes you believe that this is an implementation specific issue? Is there a standard on how BFD should work on LAGs? Do you round robin pack= ets, do you send them over one port, what do you do? GIM>> BFD (RFC 5880 + RFC 5881) over LAG, IMO, is not different from BFD ov= er any other 1 hop link and it monitors connectivity between two IP address= es regardless of through or on which LC BFD packets been originated/process= ed. Such details are implementation specific and if because of different me= thod of originating/processing BFD packets such BFD over LAG is not interop= erating, then someone got it wrong. > - any suggestion on relationship between LMM and BFD - implementation=20 > specific and doesn't seem to be appropriate in BFD standard; LMM is a generic module name. You can call it whatever you want as long as = you understand what it means.=20 GIM>> I compare with RFC 5885 which does not define MPLS and BFD inerworkin= g because it is implementation specific. IMO, similar applies to BFD over L= AG (per constituent link or not). > - are you planning to update RFC 5880 and/or RFC 5881 by introducing=20 > new BFD state variable in Section 3.3? I am not sure if having a concluded state for LAG requires updating 5880/58= 81. An implementation could just overload its internal state to match the s= tate of the LAG. They could work with the existing data structures. Does th= is mean that it does not require updating 5880/5881? I don't know .. GIM>> Changing, i.e. overloading, context of a variable defined in RFC, IMO= , is updating existing standard. If you want ineroperability, of course. > - I think that BFD over LAG member links can use 127/8 for > IPv4 address family and 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. Just trying to understand - how is this better than using a mcast address? = You don't need to reserve an address in this case. Any other benefit? GIM>> No unneccessary allocations, i.e. re-use what you have - this is good= enough for me. >=20 > Thank you for your kind consideration and I'm looking forward to your=20 > feedback. And you just got it! :) Cheers, Manav From marc@sniff.de Wed Dec 14 10:24:41 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 963E521F8B01 for ; Wed, 14 Dec 2011 10:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P50urhGIJkB5 for ; Wed, 14 Dec 2011 10:24:40 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7000121F8AFB for ; Wed, 14 Dec 2011 10:24:40 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id DC9572AA0F; Wed, 14 Dec 2011 18:24:37 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 14 Dec 2011 19:24:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1DBB85B5-2D3A-4C6B-AB9A-DA8196BA0930@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Tom Sanders , Yael Frank Dayan 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, 14 Dec 2011 18:24:41 -0000 Hello Tom and Yael, so it's proven: the memory of a mailing list is smaller than 5 month. = Actually not bad ;-) We had Juli/August already an intensive discussion = about this (see subject "Solicit comments on BFD for Interface draft") First I don't think there is "the correct" protocol. True, RFC5880 would = allow to run BFD directly on Ethernet. But: - maybe we should have added this to the draft, but it's never clear = upfront if adding something causes more confusion or more clarity: this = draft is about BFD on Bundles, i.e. Ethernet and POS (!) bundles. This = is the technical reason why the IP layer seems the right one. - the customers I know had an IP focus. Liked to have BFD packets they = already know when sniffing the wire, using ACLs etc.. Soft reason, true. - the developers (again the ones I know) preferred to re-use as much as = possible, thus IP was ideal. Another soft reason. Regards, Marc On 2011-12-14, at 17:14 , Tom Sanders wrote: > Yael, >=20 > There is no BFD that runs directly over ethernet. I think one of the > ideas behind the draft is to reuse as much of the existing BFD code as > possible. Just treating a constituent link of a LAG as a regular > physical port and running BFD on top of it looks really simple to me. > This can also easily be extended to work on ASICs that are designed to > do BFD in HW. >=20 > Why complicate this with another encapsulation and such? >=20 > Toms >=20 > On 14 December 2011 21:16, Yael Frank Dayan = wrote: >> Hi, >> Wouldn't the correct protocol be a version of BFD that runs over = Ethernet? >> How is IP relevant to a LAG member? >>=20 >> Thanks, >> Yael >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Bhatia, Manav (Manav) >> Sent: Tuesday, December 13, 2011 8:21 PM >> To: rtg-bfd@ietf.org >> Subject: BFD on LAG interfaces >>=20 >> Hi, >>=20 >> We had a very lively debate on the BFD mailing list a few months back = on standardizing BFD over the LAG interfaces. >>=20 >> We have written a draft that proposes a new approach that fixes the = issues that are seen with how folks do BFD over the LAGs today. >>=20 >> Draft available here: >> http://tools.ietf.org/id/draft-mmm-bfd-on-lags-00.txt >>=20 >> Would be great to comments from the WG. >>=20 >> Cheers, >> Marc, Mach and Manav >>=20 >> -- >>=20 >> Abstract >>=20 >> This document proposes a mechanism to run BFD on Link Aggregation >> Group (LAG) interfaces. It does so by running an independent BFD >> session on every LAG member link. >>=20 >> A dedicated well-known multicast IP address for both IPv4 and IPv6 = is >> introduced as the destination IP address of the BFD packets when >> running BFD on the member links of the LAG. >>=20 >> There is currently no standard that describes how BFD should run on >> LAG interfaces. As a result multiple non-interoperable BFD >> implementations for LAG interfaces exist. This draft provides a >> short overview as a context for the new proposed mechanism. >=20 >=20 >=20 > --=20 > Toms. >=20 -- Marc Binderberger From marc@sniff.de Wed Dec 14 10:43:30 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 90E6B21F84BD for ; Wed, 14 Dec 2011 10:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-McEOlK1E7A for ; Wed, 14 Dec 2011 10:43:30 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB13121F84BC for ; Wed, 14 Dec 2011 10:43:29 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 1FEFB2AA0F; Wed, 14 Dec 2011 18:43:28 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 14 Dec 2011 19:43:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D18877E-46AE-4D8D-AB75-22C84FCFB0C7@sniff.de> References: To: Nitin Bahadur 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, 14 Dec 2011 18:43:30 -0000 Hello Nitin, > I read through the draft and I personally do not like the idea of = using a reserved mcast address.....since it masks > one of the IP addresses used for more strict checking on whether the = packet is indeed intended for the recipient. well, the bundle links are back-to-back between the 2 devices. So it's = not a LAN with multiple (> 2) devices. The discriminator (when = non-zero), the destination multicast IP, potentially the Multicast MAC = would not be enough for a consistency check? Can you give an example for what scenario you have in mind? > I would prefer using a different UDP port number and keeping = everything the same. That way IP addr checks can be enforced. For the differentiation of per-member sessions that would do, of course. = What the mcast IP does though is it comes on Ethernet automatically with = an mcast MAC. The problem this solves is if you plan to have a tight = coupling between the LMM and BFD, mainly that BFD must go "up" before a = member link is added to the LAG, then ARP is likely not available. = Programming the mcast MAC in the Ethernet hw does the trick to receive = the BFD packets. > And based on the different UDP port, the receiving entity will know = that it needs to take constituent interface into account as well. that's true. >=20 > We have been meaning to write a draft for a long time on this....just = been bogged down with other stuff. And now we have all the different implementations in the field :-) Thanks & Regards, Marc >=20 > Thanks > Nitin >=20 >=20 > On 12/13/11 4:18 PM, "Bhatia, Manav (Manav)" = wrote: >=20 > Hi Jeff, >=20 >> IMHO BFD over LAG session type (single vs multi) should be >> transparent to the upper layer protocols. >> When L3 protocol registers with RIB for BFD status it is not >> interested in type of BFD session it is interested in its state. >> So to keep logic simple from L3 protocol point of view it would be: >>=20 >> LAG constituent down && min-links has not been met -> L3 >> protocol doesn't get notified LAG constituent down && >> min-links has been met -> L3 protocol gets BFD DOWN >=20 > This is precisely what the draft suggests. >=20 > You run BFD for a LAG and several L3 applications register for it. = Each member link of the LAG runs a BFD session. Sec 3.3 discusses about = the concluded state of the BFD session on the LAG. What is relevant for = BFD on LAG is that the concluded state is the overall state of the LAG. >=20 > If min-links are up then concluded state is UP. >=20 > L3 applications are notified once the concluded state goes down. >=20 >>=20 >> As for IPv6 I'd suggest to use LL (FF02) as this is for single hop = BFD >=20 > Yes, we should do that. >=20 > We should have also mentioned that TTL for all IPv4 multicast packets = MUST be 1. >=20 > Cheers, Manav >=20 -- Marc Binderberger From manav.bhatia@alcatel-lucent.com Wed Dec 14 11:34:25 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 9808921F84B6 for ; Wed, 14 Dec 2011 11:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKTLOAvodImo for ; Wed, 14 Dec 2011 11:34:25 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA5B21F84B5 for ; Wed, 14 Dec 2011 11:34:24 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBEJYINN029931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2011 13:34:21 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBEJYHP2022365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Dec 2011 01:04:18 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 15 Dec 2011 01:04:17 +0530 From: "Bhatia, Manav (Manav)" To: Gregory Mirsky , "rtg-bfd@ietf.org" Date: Thu, 15 Dec 2011 01:04:15 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQAMnJRQACNRhQAAAQqBYAACptBg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 19:34:25 -0000 Hi Greg, =20 > Is there a standard on how BFD should work on LAGs? Do you=20 > round robin packets, do you send them over one port, what do you do? >=20 > GIM>> BFD (RFC 5880 + RFC 5881) over LAG, IMO, is not=20 > different from BFD over any other 1 hop link and it monitors=20 There is a difference. In non lag, single hop links, there is no ambiguity = over the physical port which needs to be used when transmitting the packets= . Replace, this link with a "n" port lag, and you suddenly don't know which= link to use when TXing the packets.=20 > connectivity between two IP addresses regardless of through=20 > or on which LC BFD packets been originated/processed. Such=20 > details are implementation specific and if because of=20 > different method of originating/processing BFD packets such=20 > BFD over LAG is not interoperating, then someone got it wrong. There are multiple way to run BFD over a LAG and neither is "incorrect". 1. Spray BFD pkts in a round robin fashion over all links of LAG 2. Use one of the active ports of the LAG 3. Send BFD packets over all member links using the same Discriminator valu= es and hope that the other end will be able to make some sense out of it 4. Do what this draft suggests=20 5. some more .. If different vendors pick up different approaches to do BFD over LAG then h= ow do you get them to interoperate? In addition to this, we also want to avoid depending upon LACP to detect fa= iled member links, since LACP has convergence in O(secs). I will not rehash= the long and protracted discussion that we had last time about why operat= ors want to rely on BFD instead of .1ag and .3ah for fast link failure dete= ction. >=20 > > - any suggestion on relationship between LMM and BFD -=20 > implementation=20 > > specific and doesn't seem to be appropriate in BFD standard; >=20 > LMM is a generic module name. You can call it whatever you=20 > want as long as you understand what it means.=20 >=20 > GIM>> I compare with RFC 5885 which does not define MPLS and=20 > BFD inerworking because it is implementation specific. IMO,=20 > similar applies to BFD over LAG (per constituent link or not). Youre saying that you don't like the term LMM. Sure, it can be replaced wit= h something that's more generic. This is a nit that can be addressed. At th= is point of time I would like the WG members to focus on whether the mechan= ism described in this draft solves their problem (of running BFD over LAGs)= or not. We can deal with the stylistic issues later.=20 >=20 > > - are you planning to update RFC 5880 and/or RFC 5881 by=20 > introducing=20 > > new BFD state variable in Section 3.3? >=20 > I am not sure if having a concluded state for LAG requires=20 > updating 5880/5881. An implementation could just overload its=20 > internal state to match the state of the LAG. They could work=20 > with the existing data structures. Does this mean that it=20 > does not require updating 5880/5881? I don't know .. >=20 > GIM>> Changing, i.e. overloading, context of a variable=20 > defined in RFC, IMO, is updating existing standard. If you=20 > want ineroperability, of course. I am still not convinced that introducing a variable in the internal data s= tructures can affect interoperability. Again, as I had stated earlier - I w= ould for now want us to focus on whether we have a plausible solution to a = problem or not. >=20 > > - I think that BFD over LAG member links can use 127/8 for > > IPv4 address family and 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. >=20 > Just trying to understand - how is this better than using a=20 > mcast address? You don't need to reserve an address in this=20 > case. Any other benefit? >=20 > GIM>> No unneccessary allocations, i.e. re-use what you have=20 > - this is good enough for me. So, youre suggesting that we use an IPv4 address like 127.0.0.1 instead of = a IANA assigned multicast address. Sure, what about the MAC address? What M= AC should I use? What do I ARP for? Cheers, Manav= From gregory.mirsky@ericsson.com Wed Dec 14 12:20:08 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 15F7521F8AD8 for ; Wed, 14 Dec 2011 12:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNPR81mszInE for ; Wed, 14 Dec 2011 12:20:07 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 42DB221F8AD6 for ; Wed, 14 Dec 2011 12:20:07 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBEKK1KJ004293; Wed, 14 Dec 2011 14:20:02 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 14 Dec 2011 15:19:55 -0500 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , "rtg-bfd@ietf.org" Date: Wed, 14 Dec 2011 15:19:55 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQAMnJRQACNRhQAAAQqBYAACptBgAAHrhFA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 14 Dec 2011 20:20:08 -0000 Hi Manav, Another round of thanks for your interest and in-lining my notes with tag G= IM>>. Hope we're converging. Regards, Greg -----Original Message----- From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Wednesday, December 14, 2011 11:34 AM To: Gregory Mirsky; rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Hi Greg, =20 > Is there a standard on how BFD should work on LAGs? Do you round robin=20 > packets, do you send them over one port, what do you do? >=20 > GIM>> BFD (RFC 5880 + RFC 5881) over LAG, IMO, is not > different from BFD over any other 1 hop link and it monitors There is a difference. In non lag, single hop links, there is no ambiguity = over the physical port which needs to be used when transmitting the packets= . Replace, this link with a "n" port lag, and you suddenly don't know which= link to use when TXing the packets.=20 GIM>> IMO, it is irrelevant over which port of a LAG BFD packets been trans= ported/received. BFD packets in RFC 5881 are addressed to an IP address, no= t a physical port. Hence where an IP packet been originated and/or processe= d is irrelelvant. > connectivity between two IP addresses regardless of through=20 > or on which LC BFD packets been originated/processed. Such=20 > details are implementation specific and if because of=20 > different method of originating/processing BFD packets such=20 > BFD over LAG is not interoperating, then someone got it wrong. There are multiple way to run BFD over a LAG and neither is "incorrect". 1. Spray BFD pkts in a round robin fashion over all links of LAG 2. Use one of the active ports of the LAG 3. Send BFD packets over all member links using the same Discriminator valu= es and hope that the other end will be able to make some sense out of it 4. Do what this draft suggests=20 5. some more .. If different vendors pick up different approaches to do BFD over LAG then h= ow do you get them to interoperate? GIM>> BFD over LAG must operate according to RFC 5881 and thus any particul= ar "way" of originating and/or processing BFD control packet is, repeating = myself, irrelevant to BFD state. Modes you've listed are implementation spe= cific attempts to optimize or address some other objectives of particular v= endor, HW shortcomings and, IMNSHO, not something to standardize. In addition to this, we also want to avoid depending upon LACP to detect fa= iled member links, since LACP has convergence in O(secs). I will not rehash= the long and protracted discussion that we had last time about why operat= ors want to rely on BFD instead of .1ag and .3ah for fast link failure dete= ction. GIM>> That is the substance of the proposal, IMO: - how to run BFD over LAG's constituent links; - how to run BFD over LAG's constituent links and BFD over LAG concurrently= . And no need to argue which one is better, I'm not technology biased. >=20 > > - any suggestion on relationship between LMM and BFD -=20 > implementation=20 > > specific and doesn't seem to be appropriate in BFD standard; >=20 > LMM is a generic module name. You can call it whatever you=20 > want as long as you understand what it means.=20 >=20 > GIM>> I compare with RFC 5885 which does not define MPLS and=20 > BFD inerworking because it is implementation specific. IMO,=20 > similar applies to BFD over LAG (per constituent link or not). Youre saying that you don't like the term LMM. Sure, it can be replaced wit= h something that's more generic. This is a nit that can be addressed. At th= is point of time I would like the WG members to focus on whether the mechan= ism described in this draft solves their problem (of running BFD over LAGs)= or not. We can deal with the stylistic issues later.=20 GIM>> Manav, it is not about the term but effective standartization of inte= rnals of BFD and LMM interworking. What and how BFD signals to its clients,= IMO, is not in the scope of the BFD WG. >=20 > > - are you planning to update RFC 5880 and/or RFC 5881 by=20 > introducing=20 > > new BFD state variable in Section 3.3? >=20 > I am not sure if having a concluded state for LAG requires=20 > updating 5880/5881. An implementation could just overload its=20 > internal state to match the state of the LAG. They could work=20 > with the existing data structures. Does this mean that it=20 > does not require updating 5880/5881? I don't know .. >=20 > GIM>> Changing, i.e. overloading, context of a variable=20 > defined in RFC, IMO, is updating existing standard. If you=20 > want ineroperability, of course. I am still not convinced that introducing a variable in the internal data s= tructures can affect interoperability. Again, as I had stated earlier - I w= ould for now want us to focus on whether we have a plausible solution to a = problem or not. GIM>> I'm afraid that you hardly can control topics being discussed once yo= u submit the text for review. >=20 > > - I think that BFD over LAG member links can use 127/8 for > > IPv4 address family and 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. >=20 > Just trying to understand - how is this better than using a=20 > mcast address? You don't need to reserve an address in this=20 > case. Any other benefit? >=20 > GIM>> No unneccessary allocations, i.e. re-use what you have=20 > - this is good enough for me. So, youre suggesting that we use an IPv4 address like 127.0.0.1 instead of = a IANA assigned multicast address. Sure, what about the MAC address? What M= AC should I use? What do I ARP for? GIM>> Request to allocate Ethernet Multicast Address to be used for p2p Eth= ernet links is reasonable and in line with idea suggested in draft-fbb-mpls= -tp-ethernet-addressing-00. Cheers, Manav= From dkatz@juniper.net Wed Dec 14 14:23:03 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 3BF3211E809F for ; Wed, 14 Dec 2011 14:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQGk6lWyruZJ for ; Wed, 14 Dec 2011 14:23:02 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 07DDB11E80C6 for ; Wed, 14 Dec 2011 14:23:01 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTukhwzmP36XLsSgdq8C1wa6Y0jeC+Lz4@postini.com; Wed, 14 Dec 2011 14:23:02 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 14 Dec 2011 14:21:22 -0800 Received: from sa-nc-ipg-172-23-0-226.static.jnpr.net (sa-nc-ipg-172-23-0-226.static.jnpr.net [172.23.0.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id pBEMORP39435; Wed, 14 Dec 2011 14:24:27 -0800 (PST) (envelope-from dkatz@juniper.net) Subject: Re: BFD on LAG interfaces MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Wed, 14 Dec 2011 14:19:13 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Gregory Mirsky 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, 14 Dec 2011 22:23:03 -0000 Reading between the lines, it appears that the fundamental goal is to = replace LACP, at least as a liveness mechanism, as the detection time is = too slow. This should be called out explicitly. This means that you = need a BFD session per leg, and an aggregation mechanism for the = resulting state. On the first point, the problem is that the whole point of having LAGs = is to fold multiple links into one; as such, from the IP layer, the = component links are invisible; the service access for the individual = legs is at the Ethernet layer. Thus, from an architectural standpoint, = the only thing that makes sense would be to run BFD directly over = Ethernet (which we went out of our way to make possible in 5880 but = couldn't get any traction from the Ethernet folks to adopt it). As soon = as you try to operate at the IP layer, you run smack into = implementation-specific problems, as there is fundamentally no IP = binding to individual legs of a LAG. So to run this over IP, you = require implementations to expose the individual legs as having IP = bindings, even if they are kludged (which is what is being suggested = here). This is, well, *ugly*. Assuming that you manage to run BFD over individual legs somehow, = achieving the second point (state aggregation) does not require = modification to 5880. What it *does* require, however, is for the = BFD-over-bundle spec to call out how that aggregation occurs (an = additional state machine). What comes out of the top of that state = machine is what gets coupled to the apps. This is discussed (albeit = briefly) in RFC 5883. There's no new ground here other than to be = specific about how the state machine works. It may be necessary to run = an additional BFD session, independent of the per-leg sessions, in order = to succinctly communicate such concepts as AdminDown for the whole = bundle, etc. Such a session can run at a sedate rate since the per-leg = sessions will take care of the more intense liveness testing. As far as this particular draft goes, I think trying to make this work = over IP creates a whole pile of issues that cannot be solved in a = standard way, because it essentially requires that BFD tap into private = APIs in order to work. The real issue here is that the Ethernet folks have clearly dropped the = ball. The right answer (IMHO) is to fix LACP so that it can operate at = reasonable speeds. That *is* part of its job, no? With a LACP that Did = The Right Thing, BFD just operates over the bundle and doesn't duplicate = a bunch of functionality. Anybody go to IEEE meetings? If this is too tall an order, the Not Quite As Right thing would be to = define an Ethernet encapsulation for BFD, as it could then operate on = well-defined APIs and not be an ugly layer violation. This will still = make the Ethernet folks squeal, but it doesn't require them to do = anything other than to allocate an EtherType code point and possibly a = well-known multicast address (though even this can be punted by just = using broadcast if the link is truly point-to-point). The disagreement about physical TX port binding is simply a = manifestation of the fact that trying to do this at the IP layer is = fundamentally undefined from a standards point of view, as it requires = sending IP packets over links that have no IP binding, and as such is = fundamentally hackery. --Dave On Dec 14, 2011, at 12:19 PM, Gregory Mirsky wrote: > Hi Manav, > Another round of thanks for your interest and in-lining my notes with = tag GIM>>. Hope we're converging. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20= > Sent: Wednesday, December 14, 2011 11:34 AM > To: Gregory Mirsky; rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces >=20 > Hi Greg, >=20 >> Is there a standard on how BFD should work on LAGs? Do you round = robin=20 >> packets, do you send them over one port, what do you do? >>=20 >> GIM>> BFD (RFC 5880 + RFC 5881) over LAG, IMO, is not >> different from BFD over any other 1 hop link and it monitors >=20 > There is a difference. In non lag, single hop links, there is no = ambiguity over the physical port which needs to be used when = transmitting the packets. Replace, this link with a "n" port lag, and = you suddenly don't know which link to use when TXing the packets.=20 >=20 > GIM>> IMO, it is irrelevant over which port of a LAG BFD packets been = transported/received. BFD packets in RFC 5881 are addressed to an IP = address, not a physical port. Hence where an IP packet been originated = and/or processed is irrelelvant. >=20 >> connectivity between two IP addresses regardless of through=20 >> or on which LC BFD packets been originated/processed. Such=20 >> details are implementation specific and if because of=20 >> different method of originating/processing BFD packets such=20 >> BFD over LAG is not interoperating, then someone got it wrong. >=20 > There are multiple way to run BFD over a LAG and neither is = "incorrect". >=20 > 1. Spray BFD pkts in a round robin fashion over all links of LAG > 2. Use one of the active ports of the LAG > 3. Send BFD packets over all member links using the same Discriminator = values and hope that the other end will be able to make some sense out = of it > 4. Do what this draft suggests=20 > 5. some more .. >=20 > If different vendors pick up different approaches to do BFD over LAG = then how do you get them to interoperate? >=20 > GIM>> BFD over LAG must operate according to RFC 5881 and thus any = particular "way" of originating and/or processing BFD control packet is, = repeating myself, irrelevant to BFD state. Modes you've listed are = implementation specific attempts to optimize or address some other = objectives of particular vendor, HW shortcomings and, IMNSHO, not = something to standardize. >=20 > In addition to this, we also want to avoid depending upon LACP to = detect failed member links, since LACP has convergence in O(secs). I = will not rehash the long and protracted discussion that we had last = time about why operators want to rely on BFD instead of .1ag and .3ah = for fast link failure detection. >=20 > GIM>> That is the substance of the proposal, IMO: > - how to run BFD over LAG's constituent links; > - how to run BFD over LAG's constituent links and BFD over LAG = concurrently. > And no need to argue which one is better, I'm not technology biased. >=20 >>=20 >>> - any suggestion on relationship between LMM and BFD -=20 >> implementation=20 >>> specific and doesn't seem to be appropriate in BFD standard; >>=20 >> LMM is a generic module name. You can call it whatever you=20 >> want as long as you understand what it means.=20 >>=20 >> GIM>> I compare with RFC 5885 which does not define MPLS and=20 >> BFD inerworking because it is implementation specific. IMO,=20 >> similar applies to BFD over LAG (per constituent link or not). >=20 > Youre saying that you don't like the term LMM. Sure, it can be = replaced with something that's more generic. This is a nit that can be = addressed. At this point of time I would like the WG members to focus on = whether the mechanism described in this draft solves their problem (of = running BFD over LAGs) or not. We can deal with the stylistic issues = later.=20 >=20 > GIM>> Manav, it is not about the term but effective standartization of = internals of BFD and LMM interworking. What and how BFD signals to its = clients, IMO, is not in the scope of the BFD WG. >=20 >>=20 >>> - are you planning to update RFC 5880 and/or RFC 5881 by=20 >> introducing=20 >>> new BFD state variable in Section 3.3? >>=20 >> I am not sure if having a concluded state for LAG requires=20 >> updating 5880/5881. An implementation could just overload its=20 >> internal state to match the state of the LAG. They could work=20 >> with the existing data structures. Does this mean that it=20 >> does not require updating 5880/5881? I don't know .. >>=20 >> GIM>> Changing, i.e. overloading, context of a variable=20 >> defined in RFC, IMO, is updating existing standard. If you=20 >> want ineroperability, of course. >=20 > I am still not convinced that introducing a variable in the internal = data structures can affect interoperability. Again, as I had stated = earlier - I would for now want us to focus on whether we have a = plausible solution to a problem or not. >=20 > GIM>> I'm afraid that you hardly can control topics being discussed = once you submit the text for review. >=20 >>=20 >>> - I think that BFD over LAG member links can use 127/8 for >>> IPv4 address family and 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. >>=20 >> Just trying to understand - how is this better than using a=20 >> mcast address? You don't need to reserve an address in this=20 >> case. Any other benefit? >>=20 >> GIM>> No unneccessary allocations, i.e. re-use what you have=20 >> - this is good enough for me. >=20 > So, youre suggesting that we use an IPv4 address like 127.0.0.1 = instead of a IANA assigned multicast address. Sure, what about the MAC = address? What MAC should I use? What do I ARP for? >=20 > GIM>> Request to allocate Ethernet Multicast Address to be used for = p2p Ethernet links is reasonable and in line with idea suggested in = draft-fbb-mpls-tp-ethernet-addressing-00. >=20 > Cheers, Manav >=20 From marc@sniff.de Wed Dec 14 14:31:20 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 780CF11E80CC for ; Wed, 14 Dec 2011 14:31:20 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkOL91UmYYZI for ; Wed, 14 Dec 2011 14:31:19 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B84C811E809F for ; Wed, 14 Dec 2011 14:31:18 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 3F5F52AA0F; Wed, 14 Dec 2011 22:31:16 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 14 Dec 2011 23:31:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <487A34FD-99AB-47BD-A92F-ACAA01DED319@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" , Gregory Mirsky 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, 14 Dec 2011 22:31:20 -0000 Hello Gregory and Manav, this is a fast "match". I hope I can follow - let me try ;-) For section 2.x I think the definition of BFD over Big Pipe ("BBP") - or = "BFD over LAG" as you name it - was not section 2.1 but 2.2: ----snip----snap----snip----snap---- o BFD must work no matter what member link, packets are sent and received on. o the Rx/Tx link can change any time and/or regularly with every change pattern without causing BFD to fail This allows to use the LAG like any other interface and RFC 5880 and RFC 5881 can be used without modification. ----snip----snap----snip----snap---- and this should be in-line with your comments: >> GIM>> BFD (RFC 5880 + RFC 5881) over LAG, IMO, is not >> different from BFD over any other 1 hop link > GIM>> IMO, it is irrelevant over which port of a LAG BFD packets been = transported/received. BFD packets in RFC 5881 are addressed to an IP = address, not a physical port. Hence where an IP packet been originated = and/or processed is irrelelvant. I don't see a difference between Gregory's statements and the draft = section 2.2 - what am I missing? :-) Maybe the recommendation for round-robin is causing confusion? For me I = was reading this more as "worked well for others, give this a try". You = can ignore recommendations. Then: > GIM>> That is the substance of the proposal, IMO: > - how to run BFD over LAG's constituent links; > - how to run BFD over LAG's constituent links and BFD over LAG = concurrently. > And no need to argue which one is better, I'm not technology biased. I agree. Actually the proposal also does a "definition on the fly" of = what the BFD over LAG ("BBP") is, in section 2.2. =20 My personal view is that when you run over member links and BBP = concurrently then there is no better - they improve each other. About the "new state variable": > GIM>> I'm afraid that you hardly can control topics being discussed = once you submit the text for review. "hardly" is true but is not identical with "no" control ;-) Seriously: when we named it concluded state then there was no intention = to affect RFC5880. Actually the per-member-link sessions are RFC5880 = without any additional state. The concluded state comes with the LAG: What is relevant for BFD on LAG is that the concluded state is the overall state of the LAG. As "BFD over LAG's constituent links" doesn't have a BFD session for the = overall LAG we had to name this "overall state" somehow. We use = "concluded state". So this new state variable may exist in an implementation but then it = belongs to this draft, not to RFC5880. It has relevance for the report = back to the layer-3 clients, as described in section 4. But the packets = on the wire follow RFC5880.=20 About the destination IP address: >> GIM>> No unneccessary allocations, i.e. re-use what you have=20 >> - this is good enough for me. > GIM>> Request to allocate Ethernet Multicast Address to be used for = p2p Ethernet links is reasonable and in line with idea suggested in = draft-fbb-mpls-tp-ethernet-addressing-00. So why not the all-host multicast address? No extra allocation and comes = with a multicast MAC. Reason why I feel uncomfortable with 127/8: used by BFD for LSP = (RFC5884) already. The Multicast IP was meant for a simple = differentiation About the LMM I have to think a bit - or maybe I wait for Manav's reply = :-) Thanks for your comments! Regards, Marc On 2011-12-14, at 21:19 , Gregory Mirsky wrote: > Hi Manav, > Another round of thanks for your interest and in-lining my notes with = tag GIM>>. Hope we're converging. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20= > Sent: Wednesday, December 14, 2011 11:34 AM > To: Gregory Mirsky; rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces >=20 > Hi Greg, >=20 >> Is there a standard on how BFD should work on LAGs? Do you round = robin=20 >> packets, do you send them over one port, what do you do? >>=20 >> GIM>> BFD (RFC 5880 + RFC 5881) over LAG, IMO, is not >> different from BFD over any other 1 hop link and it monitors >=20 > There is a difference. In non lag, single hop links, there is no = ambiguity over the physical port which needs to be used when = transmitting the packets. Replace, this link with a "n" port lag, and = you suddenly don't know which link to use when TXing the packets.=20 >=20 > GIM>> IMO, it is irrelevant over which port of a LAG BFD packets been = transported/received. BFD packets in RFC 5881 are addressed to an IP = address, not a physical port. Hence where an IP packet been originated = and/or processed is irrelelvant. >=20 >> connectivity between two IP addresses regardless of through=20 >> or on which LC BFD packets been originated/processed. Such=20 >> details are implementation specific and if because of=20 >> different method of originating/processing BFD packets such=20 >> BFD over LAG is not interoperating, then someone got it wrong. >=20 > There are multiple way to run BFD over a LAG and neither is = "incorrect". >=20 > 1. Spray BFD pkts in a round robin fashion over all links of LAG > 2. Use one of the active ports of the LAG > 3. Send BFD packets over all member links using the same Discriminator = values and hope that the other end will be able to make some sense out = of it > 4. Do what this draft suggests=20 > 5. some more .. >=20 > If different vendors pick up different approaches to do BFD over LAG = then how do you get them to interoperate? >=20 > GIM>> BFD over LAG must operate according to RFC 5881 and thus any = particular "way" of originating and/or processing BFD control packet is, = repeating myself, irrelevant to BFD state. Modes you've listed are = implementation specific attempts to optimize or address some other = objectives of particular vendor, HW shortcomings and, IMNSHO, not = something to standardize. >=20 > In addition to this, we also want to avoid depending upon LACP to = detect failed member links, since LACP has convergence in O(secs). I = will not rehash the long and protracted discussion that we had last = time about why operators want to rely on BFD instead of .1ag and .3ah = for fast link failure detection. >=20 > GIM>> That is the substance of the proposal, IMO: > - how to run BFD over LAG's constituent links; > - how to run BFD over LAG's constituent links and BFD over LAG = concurrently. > And no need to argue which one is better, I'm not technology biased. >=20 >>=20 >>> - any suggestion on relationship between LMM and BFD -=20 >> implementation=20 >>> specific and doesn't seem to be appropriate in BFD standard; >>=20 >> LMM is a generic module name. You can call it whatever you=20 >> want as long as you understand what it means.=20 >>=20 >> GIM>> I compare with RFC 5885 which does not define MPLS and=20 >> BFD inerworking because it is implementation specific. IMO,=20 >> similar applies to BFD over LAG (per constituent link or not). >=20 > Youre saying that you don't like the term LMM. Sure, it can be = replaced with something that's more generic. This is a nit that can be = addressed. At this point of time I would like the WG members to focus on = whether the mechanism described in this draft solves their problem (of = running BFD over LAGs) or not. We can deal with the stylistic issues = later.=20 >=20 > GIM>> Manav, it is not about the term but effective standartization of = internals of BFD and LMM interworking. What and how BFD signals to its = clients, IMO, is not in the scope of the BFD WG. >=20 >>=20 >>> - are you planning to update RFC 5880 and/or RFC 5881 by=20 >> introducing=20 >>> new BFD state variable in Section 3.3? >>=20 >> I am not sure if having a concluded state for LAG requires=20 >> updating 5880/5881. An implementation could just overload its=20 >> internal state to match the state of the LAG. They could work=20 >> with the existing data structures. Does this mean that it=20 >> does not require updating 5880/5881? I don't know .. >>=20 >> GIM>> Changing, i.e. overloading, context of a variable=20 >> defined in RFC, IMO, is updating existing standard. If you=20 >> want ineroperability, of course. >=20 > I am still not convinced that introducing a variable in the internal = data structures can affect interoperability. Again, as I had stated = earlier - I would for now want us to focus on whether we have a = plausible solution to a problem or not. >=20 > GIM>> I'm afraid that you hardly can control topics being discussed = once you submit the text for review. >=20 >>=20 >>> - I think that BFD over LAG member links can use 127/8 for >>> IPv4 address family and 0:0:0:0:0:FFFF:127.0.0.0/104 for IPv6. >>=20 >> Just trying to understand - how is this better than using a=20 >> mcast address? You don't need to reserve an address in this=20 >> case. Any other benefit? >>=20 >> GIM>> No unneccessary allocations, i.e. re-use what you have=20 >> - this is good enough for me. >=20 > So, youre suggesting that we use an IPv4 address like 127.0.0.1 = instead of a IANA assigned multicast address. Sure, what about the MAC = address? What MAC should I use? What do I ARP for? >=20 > GIM>> Request to allocate Ethernet Multicast Address to be used for = p2p Ethernet links is reasonable and in line with idea suggested in = draft-fbb-mpls-tp-ethernet-addressing-00. >=20 > Cheers, Manav -- Marc Binderberger From manav.bhatia@alcatel-lucent.com Wed Dec 14 16:59:03 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 3D44221F86D0 for ; Wed, 14 Dec 2011 16:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHVVhmXehLIC for ; Wed, 14 Dec 2011 16:59:02 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA9F21F86AA for ; Wed, 14 Dec 2011 16:59:02 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBF0wwf6008757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2011 18:59:00 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBF0wvOo029073 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Dec 2011 06:28:57 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 15 Dec 2011 06:28:57 +0530 From: "Bhatia, Manav (Manav)" To: Dave Katz Date: Thu, 15 Dec 2011 06:28:55 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy6rvQXYbMWKdZuRZiMYBpgUrtPMQAEcIpA Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F103C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> In-Reply-To: <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 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, 15 Dec 2011 00:59:03 -0000 Hi Dave, =20 > Reading between the lines, it appears that the fundamental=20 > goal is to replace LACP, at least as a liveness mechanism, as=20 > the detection time is too slow. This should be called out=20 > explicitly. This means that you need a BFD session per leg,=20 > and an aggregation mechanism for the resulting state. You've put it quite succinctly.=20 Really, the goal is simple - How do we run BFD over a LAG interfaces while = ensuring that link failures don't take more than a few milli secs to be det= ected. LACP was out since its too slow. Eth OAM was out since operators in = IP/MPLS space wanted to stay away from it. That left us with just BFD to mo= dify, which is what we did. >=20 > On the first point, the problem is that the whole point of=20 > having LAGs is to fold multiple links into one; as such,=20 > from the IP layer, the component links are invisible; the=20 Yes. > service access for the individual legs is at the Ethernet=20 > layer. Thus, from an architectural standpoint, the only=20 > thing that makes sense would be to run BFD directly over=20 > Ethernet (which we went out of our way to make possible in=20 > 5880 but couldn't get any traction from the Ethernet folks to=20 Which is precisely why we wanted to do this at the BFD layer. > adopt it). As soon as you try to operate at the IP layer,=20 > you run smack into implementation-specific problems, as there=20 > is fundamentally no IP binding to individual legs of a LAG. =20 > So to run this over IP, you require implementations to expose=20 > the individual legs as having IP bindings, even if they are=20 > kludged (which is what is being suggested here). This is,=20 Yes its slight convoluted as you let the IP layer decide the fate of the lo= wer layer. >=20 > Assuming that you manage to run BFD over individual legs=20 > somehow, achieving the second point (state aggregation) does=20 > not require modification to 5880. What it *does* require,=20 > however, is for the BFD-over-bundle spec to call out how that=20 > aggregation occurs (an additional state machine). What comes=20 > out of the top of that state machine is what gets coupled to=20 > the apps. This is discussed (albeit briefly) in RFC 5883. =20 > There's no new ground here other than to be specific about=20 > how the state machine works. It may be necessary to run an=20 > additional BFD session, independent of the per-leg sessions,=20 > in order to succinctly communicate such concepts as AdminDown=20 > for the whole bundle, etc. Such a session can run at a=20 > sedate rate since the per-leg sessions will take care of the=20 > more intense liveness testing. And this is the second mode that we describe in Sec 4. The additional BFD s= ession that youre alluding to is the BFD over the Big Pipe in our document = and it does exactly what you have described. We have BFD sessions per membe= r links of the LAG that control the state of that link. We then have an add= itional BFD session, independent of the per member LAG sessions, which cont= rols the state of the whole LAG. > As far as this particular draft goes, I think trying to make=20 > this work over IP creates a whole pile of issues that cannot=20 > be solved in a standard way, because it essentially requires=20 > that BFD tap into private APIs in order to work. I am not sure I understand what private APIs are you referring to. I think = the confusion stems from the two modes that we have defined in Sec 4.=20 In the first mode we just run BFD over the member links. There is no additi= onal BFD running over the whole bundle. In this mode, BFD is simply replaci= ng LACP. It keeps track of all the links that are alive and informs the LAG= manager (or some entity, beyond the scope of this document) about it. The = IP interface over the LAG is torn down once the number of remaining links r= eaches the minimum threshold number. BFD is thus used to decide the fate of= an IP interface.=20 We had kept this mode as the default mode. I am now having second thoughts on whether this is the right thing to do or= not. Then there is the second mode described in Section 4. Establish BFD sessions over each member link. The aggregate result of this = decides the fate of only the LAG (and not that of the IP interface defined = above it). Establish another BFD session over the LAG (which is what most i= mplementations do today) that runs sedate timers and ensures IP reachabilit= y with the other end. This mode gives us the best of both worlds. Would it make more sense to keep this mode as default and completely do awa= y with the first mode that we have defined? > The real issue here is that the Ethernet folks have clearly=20 > dropped the ball. The right answer (IMHO) is to fix LACP so=20 > that it can operate at reasonable speeds. That *is* part of=20 > its job, no? With a LACP that Did The Right Thing, BFD just=20 > operates over the bundle and doesn't duplicate a bunch of=20 > functionality. Anybody go to IEEE meetings? That would be ideal.=20 Cheers, Manav= From dkatz@juniper.net Wed Dec 14 19:02: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 311471F0C69 for ; Wed, 14 Dec 2011 19:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZNPUBgKCOer for ; Wed, 14 Dec 2011 19:02:00 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 77FF01F0C47 for ; Wed, 14 Dec 2011 19:02:00 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTuljJ0kWh8RopV+izAGY+HdF6423rhqW@postini.com; Wed, 14 Dec 2011 19:02:00 PST Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 14 Dec 2011 19:01:27 -0800 Received: from sa-nc-ipg-172-23-0-226.static.jnpr.net (sa-nc-ipg-172-23-0-226.static.jnpr.net [172.23.0.226]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id pBF36bP46942; Wed, 14 Dec 2011 19:06:37 -0800 (PST) (envelope-from dkatz@juniper.net) Subject: Re: BFD on LAG interfaces MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F103C@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 14 Dec 2011 19:01:23 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> <7C362EEF9C7896468B36C9B79200D8350D026F103C@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" 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: Thu, 15 Dec 2011 03:02:01 -0000 On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote: >=20 >> As far as this particular draft goes, I think trying to make=20 >> this work over IP creates a whole pile of issues that cannot=20 >> be solved in a standard way, because it essentially requires=20 >> that BFD tap into private APIs in order to work. >=20 > I am not sure I understand what private APIs are you referring to. I = think the confusion stems from the two modes that we have defined in Sec = 4.=20 My point is that running IP over an individual leg is an unnatural act, = as it is architecturally incompatible with how LAGs are supposed to work = (IMHO). As a result, implementors have to hack something into their = implementations to sort-of-pretend-but-not-really that IP is enabled on = the individual legs. There is no good way to spec such a thing because there isn't supposed = to be any IP binding to the individual leg. What you're doing, in = effect, is modifying the definition of a LAG in order to shoehorn BFD = into the picture, which is rather out-of-scope for the BFD group (and = for the IETF in general). I don't see how it would be possible to = standardize such a thing. >=20 > In the first mode we just run BFD over the member links. There is no = additional BFD running over the whole bundle. In this mode, BFD is = simply replacing LACP. It keeps track of all the links that are alive = and informs the LAG manager (or some entity, beyond the scope of this = document) about it. The IP interface over the LAG is torn down once the = number of remaining links reaches the minimum threshold number. BFD is = thus used to decide the fate of an IP interface.=20 >=20 > We had kept this mode as the default mode. >=20 > I am now having second thoughts on whether this is the right thing to = do or not. It's a reasonable thing if all you're doing is replacing LACP with BFD = as the per-leg liveness test; it makes BFD invisible to applications, = as the service interface is the top of the LAG. This is subtly = different than having a BFD-over-the-top session in addition to the = individual legs, as doing so provides visible BFD semantics rather than = LAG semantics, and the service interface reflects those semantics (so = you can potentially do things like AdminDown and the like). >=20 > Then there is the second mode described in Section 4. >=20 > Establish BFD sessions over each member link. The aggregate result of = this decides the fate of only the LAG (and not that of the IP interface = defined above it). Establish another BFD session over the LAG (which is = what most implementations do today) that runs sedate timers and ensures = IP reachability with the other end. This mode gives us the best of both = worlds. >=20 > Would it make more sense to keep this mode as default and completely = do away with the first mode that we have defined? I'm agnostic about the choices; I can see some benefit in both. But = the real problem is how to do the per-link stuff in a reasonable way. --Dave From manav.bhatia@alcatel-lucent.com Wed Dec 14 20:40:59 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 61CFD21F8B05 for ; Wed, 14 Dec 2011 20:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se5iTuUBwsbw for ; Wed, 14 Dec 2011 20:40:58 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6B08C21F8B03 for ; Wed, 14 Dec 2011 20:40:58 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pBF4eref019571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2011 22:40:55 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBF4eqbH003289 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Dec 2011 10:10:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 15 Dec 2011 10:10:51 +0530 From: "Bhatia, Manav (Manav)" To: Dave Katz Date: Thu, 15 Dec 2011 10:10:50 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy61eyWeptsA+jdTsGXcN1N2GtpxwABzLVQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F1077@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> <7C362EEF9C7896468B36C9B79200D8350D026F103C@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 04:40:59 -0000 Hi Dave, I think philosophically we're having a similar discussion that we had many = many moons ago over BGP being extended to carry non routing information. Fe= w asserted that it made trifle little sense for BGP to carry all the additi= onal information it was being envisaged to carry. However, the conclusion d= rawn after a long protracted discussion was that if BGP is extensible and c= an do something, then why reinvent the wheel and why not use the existing m= echanism instead? In a similar vein, we have an issue here (faster detection of failed links)= that needs to be addressed. BFD today on LAG doesn't really work (explaine= d in the draft). This needs to be fixed. We can either approach IEEE and wa= it endlessly for them to come up with something, or we can do something on = our own. Its not an engineering driven problem - it's a problem that people out ther= e are seeing (there were operators who did speak up last time). What we're saying is that while BFD was not originally meant to monitor the= forwarding plane of the constituent links of a LAG, lets do it now, becaus= e there is a need. Does it require us to pretend a few things? Yes - maybe = it does. And, mostly it doesn't.=20 More inline .. > There is no good way to spec such a thing because there isn't=20 > supposed to be any IP binding to the individual leg. What=20 > you're doing, in effect, is modifying the definition of a LAG=20 > in order to shoehorn BFD into the picture, which is rather =20 I don't think we're doing anything to the LAG (http://en.wikipedia.org/wiki= /Link_aggregation). We're not changing what the LAG is. What we're perhaps = changing is the part where LACP fits in. We're saying that instead of using= LACPDUs to detect failed links we'll use BFD. To avoid the deadlock betwee= n L3 and the lower layers, we will use multicast. This is one component of = the solution and involves no layer violation. On top of this you may run the regular RFC 5880 compliant BFD with *zero* c= hanges. The two together should solve all the problems. However, its NOT mandatory = to run the on-the-top-BFD session. > > In the first mode we just run BFD over the member links.=20 > There is no additional BFD running over the whole bundle. In=20 > this mode, BFD is simply replacing LACP. It keeps track of=20 > all the links that are alive and informs the LAG manager (or=20 > some entity, beyond the scope of this document) about it. The=20 > IP interface over the LAG is torn down once the number of=20 > remaining links reaches the minimum threshold number. BFD is=20 > thus used to decide the fate of an IP interface.=20 > >=20 > > We had kept this mode as the default mode. > >=20 > > I am now having second thoughts on whether this is the=20 > right thing to do or not. >=20 > It's a reasonable thing if all you're doing is replacing LACP=20 > with BFD as the per-leg liveness test; it makes BFD=20 > invisible to applications, as the service interface is the=20 > top of the LAG. =20 This is the default mode that we're suggesting. Just run micro BFD sessions= on each member link. Applications are oblivious to the presence of BFD. Th= ey only rely on the state of the LAG. > This is subtly different than having a=20 > BFD-over-the-top session in addition to the individual legs,=20 > as doing so provides visible BFD semantics rather than LAG=20 So, I think this is where we have a disconnect. To me, the micro BFD sessions just have the visibility at the LAG level. Th= ey control the fate of the LAG. You don't need to run the BFD-over-the-top-session, but if you want to do t= hat they that session is completely independent of the micro BFD sessions t= hat you are running underneath. > > Would it make more sense to keep this mode as default and=20 > completely do away with the first mode that we have defined? >=20 > I'm agnostic about the choices; I can see some benefit in=20 > both. =20 Same here. Which is why we decided to include both.=20 > But the real problem is how to do the per-link stuff=20 > in a reasonable way. I think what we're proposing is quite reasonable. You cant use Unicast IPv4 (for ARP resolution etc) You don't want to define a new IEEE encapsulation where you get a new ether= type from IEEE. You want the ASICs that do BFD in HW to support this scheme with zero chang= es. You want to reuse as much code as possible for implementing the new mechani= sm. You want the solution to be generic enough to work in IP/MPLS and non IP/MP= LS environments. If you look at what we're proposing then it meets all the above requirement= s. 1. Use a well known IANA allocated multicast IP address.=20 2. Derive the dest MAC from the dest IP.=20 3. Use your port's MAC as the source MAC. 4. Start sending BFD packets as described in rfc 5880. One can pretty much = use the same state machine that's described there. 5. Use the Your Discriminator value to demultiplex the BFD packets to the r= ight micro BFD session (BFD session on member link). 6. If either the remote system signals Down state or the Detection Time exp= ires, the micro BFD session advances to Down state and the LAG manager is i= nformed which promptly removes the member link from the LAG. The rest would be taken care of by the LAG manager as its done in all the e= xisting implementations today. Cheers, Manav= From mach.chen@huawei.com Wed Dec 14 21:02:30 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 9B24721F8ABE for ; Wed, 14 Dec 2011 21:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkNKq-5c4U1t for ; Wed, 14 Dec 2011 21:02:29 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7D90321F8ABD for ; Wed, 14 Dec 2011 21:02:29 -0800 (PST) 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 <0LW8006HUB82XA@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 15 Dec 2011 13:00:02 +0800 (CST) Received: from szxrg01-dlp.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 <0LW800BXMB82TQ@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Thu, 15 Dec 2011 13:00:02 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFV44945; Thu, 15 Dec 2011 12:59:53 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 15 Dec 2011 12:59:47 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.67]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Thu, 15 Dec 2011 12:59:51 +0800 Date: Thu, 15 Dec 2011 04:59:50 +0000 From: Mach Chen Subject: RE: BFD on LAG interfaces In-reply-to: X-Originating-IP: [10.108.4.61] To: Dave Katz , "Bhatia, Manav (Manav)" 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: BFD on LAG interfaces Thread-index: Acy5xAc2rqbrLGipReylGpRIoRTZpQAMnJRQACNRhQAAAQqBYAACptBgAAHrhFD//6JPgIAALJ6AgAAiOID//3Vu0A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> <7C362EEF9C7896468B36C9B79200D8350D026F103C@INBANSXCHMBSA1.in.alcatel-lucent.com> 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, 15 Dec 2011 05:02:30 -0000 Hi Dave, Please see inline... > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Dave Katz > Sent: Thursday, December 15, 2011 11:01 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAG interfaces > > > On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote: > > > >> As far as this particular draft goes, I think trying to make > >> this work over IP creates a whole pile of issues that cannot > >> be solved in a standard way, because it essentially requires > >> that BFD tap into private APIs in order to work. > > > > I am not sure I understand what private APIs are you referring to. I think the > confusion stems from the two modes that we have defined in Sec 4. > > My point is that running IP over an individual leg is an unnatural act, as it is > architecturally incompatible with how LAGs are supposed to work (IMHO). As Cited from RFC 5880: Section 1.: Introduction "The goal of Bidirectional Forwarding Detection (BFD) is to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and, to the extent possible, the forwarding engines themselves. 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." Section 2. Design ".BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links (so long as there is some return path, of course)." According to the above description (e.g., any media, any protocol layer, direct physical links...), IMHO, running BFD over an individual leg should be one of the goals of BFD and it is allowed and natural. > a result, implementors have to hack something into their implementations to > sort-of-pretend-but-not-really that IP is enabled on the individual legs. I agree if the LAG is an L2 interface, but for an IP enabled LAG, the individual legs could be IP enabled as well. Suppose that if the solution is applied to Bundle interface. > > There is no good way to spec such a thing because there isn't supposed to be > any IP binding to the individual leg. What you're doing, in effect, is modifying > the definition of a LAG in order to shoehorn BFD into the picture, which is > rather out-of-scope for the BFD group (and for the IETF in general). I don't see > how it would be possible to standardize such a thing. I think the question is that do we really want to solve the issue, whether BFD is a proper tool? According the discussions on the list, the requirements from some SPs, several individual similar implementations in the field, IMHO, the answer is yes. Actually, the draft proposes a new application of BFD, the client is the LAG/Bundle Interface. Best regards, Mach > > > > In the first mode we just run BFD over the member links. There is no > additional BFD running over the whole bundle. In this mode, BFD is simply > replacing LACP. It keeps track of all the links that are alive and informs the LAG > manager (or some entity, beyond the scope of this document) about it. The IP > interface over the LAG is torn down once the number of remaining links reaches > the minimum threshold number. BFD is thus used to decide the fate of an IP > interface. > > > > We had kept this mode as the default mode. > > > > I am now having second thoughts on whether this is the right thing to do or > not. > > It's a reasonable thing if all you're doing is replacing LACP with BFD as the > per-leg liveness test; it makes BFD invisible to applications, as the service > interface is the top of the LAG. This is subtly different than having a > BFD-over-the-top session in addition to the individual legs, as doing so provides > visible BFD semantics rather than LAG semantics, and the service interface > reflects those semantics (so you can potentially do things like AdminDown and > the like). > > > > Then there is the second mode described in Section 4. > > > > Establish BFD sessions over each member link. The aggregate result of this > decides the fate of only the LAG (and not that of the IP interface defined above > it). Establish another BFD session over the LAG (which is what most > implementations do today) that runs sedate timers and ensures IP reachability > with the other end. This mode gives us the best of both worlds. > > > > Would it make more sense to keep this mode as default and completely do > away with the first mode that we have defined? > > I'm agnostic about the choices; I can see some benefit in both. But the real > problem is how to do the per-link stuff in a reasonable way. > > --Dave From gregimirsky@gmail.com Wed Dec 14 21:52:36 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 B956C21F8797 for ; Wed, 14 Dec 2011 21:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDQc-XNUuIpp for ; Wed, 14 Dec 2011 21:52:35 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 159B721F8783 for ; Wed, 14 Dec 2011 21:52:31 -0800 (PST) Received: by ggnk5 with SMTP id k5so1651146ggn.31 for ; Wed, 14 Dec 2011 21:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2XNQaFbg1JqpOsw6KMnNzUl0gjnnSWQnd5HjGzzpjaQ=; b=O8RLZY6Pdu85iiCfDg6tYVQQjarujwzXHw714s/Md5WYvCqzdXXygKGBp2nt1/3ppv g+Jif62r75x8HNTPoujnRwdkAUaEQ7ZkQUnHz7GCI8c1gRJ6CJPjMJos7RC/ecpsoDP1 0PWmt9zSrQlCugqv5+iRo7EnGexTxoFGYdp9A= MIME-Version: 1.0 Received: by 10.182.54.33 with SMTP id g1mr842689obp.19.1323928351389; Wed, 14 Dec 2011 21:52:31 -0800 (PST) Received: by 10.182.56.234 with HTTP; Wed, 14 Dec 2011 21:52:31 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> <7C362EEF9C7896468B36C9B79200D8350D026F103C@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 14 Dec 2011 21:52:31 -0800 Message-ID: Subject: Re: BFD on LAG interfaces From: Greg Mirsky To: Dave Katz Content-Type: multipart/alternative; boundary=14dae93b648a17b85b04b41b17fd 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, 15 Dec 2011 05:52:36 -0000 --14dae93b648a17b85b04b41b17fd Content-Type: text/plain; charset=ISO-8859-1 Dear Dave and All, I think that Mach brought the right point and that problem we can work is not just BFD over LAG's constituent link but, as Dave pointed earlier, BFD over Ethernet, with or without IP addressing. And I'll draw parallel with RFC 5885 and RFC 6428 that use BFD over MPLS, i.e. ACH VCCV encapsulation without IP header. Regards, Greg On Wed, Dec 14, 2011 at 7:01 PM, Dave Katz wrote: > > On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote: > > > >> As far as this particular draft goes, I think trying to make > >> this work over IP creates a whole pile of issues that cannot > >> be solved in a standard way, because it essentially requires > >> that BFD tap into private APIs in order to work. > > > > I am not sure I understand what private APIs are you referring to. I > think the confusion stems from the two modes that we have defined in Sec 4. > > My point is that running IP over an individual leg is an unnatural act, as > it is architecturally incompatible with how LAGs are supposed to work > (IMHO). As a result, implementors have to hack something into their > implementations to sort-of-pretend-but-not-really that IP is enabled on the > individual legs. > > There is no good way to spec such a thing because there isn't supposed to > be any IP binding to the individual leg. What you're doing, in effect, is > modifying the definition of a LAG in order to shoehorn BFD into the > picture, which is rather out-of-scope for the BFD group (and for the IETF > in general). I don't see how it would be possible to standardize such a > thing. > > > > > In the first mode we just run BFD over the member links. There is no > additional BFD running over the whole bundle. In this mode, BFD is simply > replacing LACP. It keeps track of all the links that are alive and informs > the LAG manager (or some entity, beyond the scope of this document) about > it. The IP interface over the LAG is torn down once the number of remaining > links reaches the minimum threshold number. BFD is thus used to decide the > fate of an IP interface. > > > > We had kept this mode as the default mode. > > > > I am now having second thoughts on whether this is the right thing to do > or not. > > It's a reasonable thing if all you're doing is replacing LACP with BFD as > the per-leg liveness test; it makes BFD invisible to applications, as the > service interface is the top of the LAG. This is subtly different than > having a BFD-over-the-top session in addition to the individual legs, as > doing so provides visible BFD semantics rather than LAG semantics, and the > service interface reflects those semantics (so you can potentially do > things like AdminDown and the like). > > > > Then there is the second mode described in Section 4. > > > > Establish BFD sessions over each member link. The aggregate result of > this decides the fate of only the LAG (and not that of the IP interface > defined above it). Establish another BFD session over the LAG (which is > what most implementations do today) that runs sedate timers and ensures IP > reachability with the other end. This mode gives us the best of both worlds. > > > > Would it make more sense to keep this mode as default and completely do > away with the first mode that we have defined? > > I'm agnostic about the choices; I can see some benefit in both. But the > real problem is how to do the per-link stuff in a reasonable way. > > --Dave > > --14dae93b648a17b85b04b41b17fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Dave and All,
I think that Mach brought the right point and that pr= oblem we can work is not just BFD over LAG's constituent link but, as D= ave pointed earlier, BFD over Ethernet, with or without IP addressing. And = I'll draw parallel with RFC 5885 and RFC 6428 that use BFD over MPLS, i= .e. ACH VCCV encapsulation without IP header.

Regards,
Greg

On Wed, Dec 14, 2011= at 7:01 PM, Dave Katz <dkatz@juniper.net> wrote:

On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote:
>
>> As far as this particular draft goes, I think trying to make
>> this work over IP creates a whole pile of issues that cannot
>> be solved in a standard way, because it essentially requires
>> that BFD tap into private APIs in order to work.
>
> I am not sure I understand what private APIs are you referring to. I t= hink the confusion stems from the two modes that we have defined in Sec 4.<= br>
My point is that running IP over an individual leg is an unnatural ac= t, as it is architecturally incompatible with how LAGs are supposed to work= (IMHO). =A0As a result, implementors have to hack something into their imp= lementations to sort-of-pretend-but-not-really that IP is enabled on the in= dividual legs.

There is no good way to spec such a thing because there isn't supposed = to be any IP binding to the individual leg. =A0What you're doing, in ef= fect, is modifying the definition of a LAG in order to shoehorn BFD into th= e picture, which is rather out-of-scope for the BFD group (and for the IETF= in general). =A0I don't see how it would be possible to standardize su= ch a thing.

>
> In the first mode we just run BFD over the member links. There is no a= dditional BFD running over the whole bundle. In this mode, BFD is simply re= placing LACP. It keeps track of all the links that are alive and informs th= e LAG manager (or some entity, beyond the scope of this document) about it.= The IP interface over the LAG is torn down once the number of remaining li= nks reaches the minimum threshold number. BFD is thus used to decide the fa= te of an IP interface.
>
> We had kept this mode as the default mode.
>
> I am now having second thoughts on whether this is the right thing to = do or not.

It's a reasonable thing if all you're doing is replacing LACP= with BFD as the per-leg liveness test; =A0it makes BFD invisible to applic= ations, as the service interface is the top of the LAG. =A0This is subtly d= ifferent than having a BFD-over-the-top session in addition to the individu= al legs, as doing so provides visible BFD semantics rather than LAG semanti= cs, and the service interface reflects those semantics (so you can potentia= lly do things like AdminDown and the like).
>
> Then there is the second mode described in Section 4.
>
> Establish BFD sessions over each member link. The aggregate result of = this decides the fate of only the LAG (and not that of the IP interface def= ined above it). Establish another BFD session over the LAG (which is what m= ost implementations do today) that runs sedate timers and ensures IP reacha= bility with the other end. This mode gives us the best of both worlds.
>
> Would it make more sense to keep this mode as default and completely d= o away with the first mode that we have defined?

I'm agnostic about the choices; =A0I can see some benefit in both= . =A0But the real problem is how to do the per-link stuff in a reasonable w= ay.

--Dave


--14dae93b648a17b85b04b41b17fd-- From Alexander.Vainshtein@ecitele.com Thu Dec 15 04:26:35 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 3218521F8531 for ; Thu, 15 Dec 2011 04:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.175 X-Spam-Level: X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3QqAawZjTyU for ; Thu, 15 Dec 2011 04:26:34 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id BB63521F8487 for ; Thu, 15 Dec 2011 04:26:33 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-216.messagelabs.com!1323951990!7562874!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 24613 invoked from network); 15 Dec 2011 12:26:31 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-15.tower-216.messagelabs.com with SMTP; 15 Dec 2011 12:26:31 -0000 X-AuditID: 93eaf2e8-b7f276d000000ac3-f3-4ee9e8837f81 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 30.15.02755.388E9EE4; Thu, 15 Dec 2011 14:30:59 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 15 Dec 2011 14:26:29 +0200 From: Alexander Vainshtein To: Greg Mirsky , Dave Katz , "Bhatia, Manav (Manav)" , Nitin Bahadur Date: Thu, 15 Dec 2011 14:26:28 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAAAFq0A Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIJsWRmVeSWpSXmKPExsUy+dWnL7rNL176GTQ0SFos6D3IYvFt2lNW izn37rFaNPS2s1l8/rON0YHVo/XZXlaPnbPusnssWfKTyeN601X2AJaoBkabxLy8/JLEklSF lNTiZFulgKLMssTkSiWFzBRbJUMlhYKcxOTU3NS8ElulxIKC1LwUJTsuG6BgZp5Cal5yfkpm Xrqtkmewv66FhamlrqGSnZqyobE1V0hGZrFCqm5uYmaOQm5qcXFieqoCUATk9LyU1BSFtPwi hZKMVIWihMnMGbd3XGQsOO5T8el1M0sD4wzbLkZODgkBE4m+M3/YIWwxiQv31rN1MXJxCAns ZpTY8vcFK4QzjVHi+IYPTCBVbAK2EptW3wWrEhFYySjR29DOCpJgFtCUaDrxGWwUi4CqxKZH VxhBbGEBJYlVE36BxUUElCW2373PCGEbSVzZOJUNxOYVCJS4uecdC4jNCHTG91NrmCBmikvc ejKfCeI8AYkle84zQ9iiEi8f/2OFqBeVuNO+nhGi3kDi3PaN7BC2tsSyha+ZIeYLSpyc+YQF oldS4uCKGywTGEVnIVkxC0n7LCTts5C0L2BkWcUomZlTUJKUm25gpJtfWqKXmpxZkpqTqpec n7uJEZJUXuxgvH1G8xCjAAejEg/viqMv/IRYE8uKK3MPMUpyMCmJ8oo/e+knxJeUn1KZkVic EV9UmpNafIhRgoNZSYS3ay9QOW9KYmVValE+TMoCGKITmaW4k/NBMVsSb2xggMJREuftTn7j KySQDkxi2ampBalFMK0yHBxKErxcz4E2ChalpqdWpGXmlCCkmTg4QTbzAG3+DXIVb3FBYm5x ZjpE/hSjMcfez9/PMHKc+wskhVjy8vNSpcR5JUDGCYCUZpTmwU0D5ZT6////v2IUB/pcmPcA yEAeYGKEm/cKaBUT0KrtYSBPFgMzBFxKqoHR6aBKzNolTgclNkQUlMm91dOYOvPj4ymi3f1a 2/WuLyk7Yy3Q7TbhYc+tDL490W1ND4/cfXTCYt8lhdaMk6f7CjeZnOE5aOlkIXLbdnHwjb6z TwNrDp9buI7T/NjVj4XZDnHtbvK5VqG3+/n1HztHv1i+MvxZ5o5czSP/dz3wXtrWtd1rX94R JZbijERDLeai4kQAkgPj+AQEAAA= 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, 15 Dec 2011 12:26:35 -0000 Resending as plain text - the HTML one has exceeded the 4oK limit... Regards, Sasha From: Alexander Vainshtein Sent: Thursday, December 15, 2011 2:22 PM To: 'Greg Mirsky'; Dave Katz; 'Bhatia, Manav (Manav)'; 'Nitin Bahadur' Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Manav, Dave, Greg, Nitin and all, Several comments if you do not mind. And I apologize in advance for a rather= long email. Here is my understanding of the problem we try to solve: 1. We are dealing with a LAG between a pair of, say adjacent routers that is= :: a. Comprised of links that do not support detection of failure at the physic= al layer (e.g., loss of optical power) =96 if they were, we would not need B= FD to do the same. (There are several scenarios when detection of link failu= re at the physical layer is problematic in the real-world deployments) b. Expected to go down while some of the comprising links are still up (othe= rwise the regular 1-hop BFD session would probably do the job). 2. We want to detect the =93insufficient number of active =A0links=94 condit= ion much faster than could be done by using standard LACP, and to bring the= LAG down based on this condition. 3. The situation when LAG goes down due to insufficient number of active lin= ks must be reversible, i.e., the LAG must be able to go UP once this conditi= on disappears. Do these notes capture the problem space correctly? Or did I miss something= important? One point that is not clear to me is the timeframe for bringing constituent= links of a LAG up. I would expect that the requirements for that could be m= uch more relaxed (e.g., in order to avoid link flapping). Is that correct? I= f it is, one possible implication is that it is possible to use different me= chanisms for bringing links DOWN and UP. To the best of my understanding, th= is is how BFD is supposed to be used with routing adjacencies today, i.e. BF= D can bring the adjacency DOWN quite fast, but it has to be brought UP by th= e appropriate routing protocol. When it comes to the solution space, there seem to be several candidates: 1. Improved (faster) LACP. This has been suggested by Dave, but I have my do= ubts regarding this course of action (in addition to LACP being owned by IEE= E 802.1): a. LACP is one of the IEEE 802 SLOW protocols. The summary rate of all these= protocols per link is limited by IEEE to 10 per second b. LACP frame format allows just one bit to define the expected peer transmi= ssion interval (1=94 or 30=94). =A0 2. IEEE 802.1ag (Ethernet CFM). This could definitely do the job, but, as me= ntioned by Shane on this list, is operationally heavy. You would probably ha= ve to treat each constituent link of LAG as a separate MA with a distinct na= me; configure a separate MEP with its own =A0MEP ID on both sides of the lin= k etc. 3. BFD in some special encapsulation: a. Any such encapsulation must provide for distinguishing between a BFD sess= ion that is supposed to run over the LAG as a whole and a BFD session that i= s supposed to run over a specific constituent link of the LAG. Ability to di= stinguish between these should exist even before the session has been fully= established (i.e., when the Active side sends out a packet with Your Discri= minator set to 0). =A0This looks to me as an absolute requirement b. The nascent BFD session that has been identified as link-specific would b= e bound to the constituent physical link from which its first packet has bee= n received c. BFD packets that have been received with a valid Your Discrimination that= has been associated with a specific physical link but came =A0from a differ= ent physical link MUST be discarded (similar to what happens with received B= FD packets that fail the authentication checks) d. Failure of a BFD session that has been bound to a specific constituent li= nk of a LAG would be interpreted as the link going DOWN, and an appropriate= indication passed to the Aggregator(see IEEE 802.3-2005, Clause 43) so that= it can: i. Disable collection and distribution on that link ii. Declare LAG DOWNM if the number of active links has decreased below the= minimal number of links, and pass this indication to various MAC clients 4. If LACP is used with the LAG in question, bringing the links UP (and, if= necessary, bringing LAG as a whole UP) can be relegated to it. There is no= need to overload BFD (or any other solution =96 excluding, of course, faste= r LACP) with this functionality. This means that IP-based BFD encapsulations= can be safely used as solutions in this case. a. The BFD session using an IP-based encapsulation that has been bound to a= link in a LAG that went DOWN would wait for LAG coming UP again in order to= be restarted. b. This scheme seems to eliminate the potential deadlock mentioned by Manav= in his response to Nitin. i. IMHO and FWIW the approach described by Nitin (a dedicated UDP port) is p= referable ii. In any way i suspect that usage of IP encapsulations with multicast IP a= ddresses would not help: If LAG, as an IP interface, goes down, it may safel= y discard any IP packets it receives 5. If LACP is not used with the LAG in question, a BFD encapsulation that do= es not rely on IP/UDP (as proposed by Dave) looks like the only possible sol= ution in this class: a. Once the link-bound session goes =A0DOWN, the BFD state machine tries to= bring it up again b. Once it is UP, this session indicates to the Aggregator that the link can= be used for collection and distribution c. The Aggregator brings UP the LAG as a whole towards MAC clients if there= is enough active constituent links. IMHO and FWIW such an approach would minimize (and, in the case of BFD runni= ng directly over Ethernet, completely eliminate) architectural violations. As such, it would be (hopefully) backward compatible both with the existing= LAG implementations and existing BFD ones. Again, did I miss something? Regards, =A0=A0=A0=A0Sasha From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Greg Mirsky Sent: Thursday, December 15, 2011 7:53 AM To: Dave Katz Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG interfaces Dear Dave and All, I think that Mach brought the right point and that problem we can work is no= t just BFD over LAG's constituent link but, as Dave pointed earlier, BFD ove= r Ethernet, with or without IP addressing. And I'll draw parallel with RFC 5= 885 and RFC 6428 that use BFD over MPLS, i.e. ACH VCCV encapsulation without= IP header. Regards, Greg On Wed, Dec 14, 2011 at 7:01 PM, Dave Katz wrote: On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote: > >> As far as this particular draft goes, I think trying to make >> this work over IP creates a whole pile of issues that cannot >> be solved in a standard way, because it essentially requires >> that BFD tap into private APIs in order to work. > > I am not sure I understand what private APIs are you referring to. I think= the confusion stems from the two modes that we have defined in Sec 4. My point is that running IP over an individual leg is an unnatural act, as i= t is architecturally incompatible with how LAGs are supposed to work (IMHO).= =A0As a result, implementers have to hack something into their implementati= ons to sort-of-pretend-but-not-really that IP is enabled on the individual l= egs. There is no good way to spec such a thing because there isn't supposed to be= any IP binding to the individual leg. =A0What you're doing, in effect, is m= odifying the definition of a LAG in order to shoehorn BFD into the picture,= which is rather out-of-scope for the BFD group (and for the IETF in general= ). =A0I don't see how it would be possible to standardize such a thing. > > In the first mode we just run BFD over the member links. There is no addit= ional BFD running over the whole bundle. In this mode, BFD is simply replaci= ng LACP. It keeps track of all the links that are alive and informs the LAG= manager (or some entity, beyond the scope of this document) about it. The I= P interface over the LAG is torn down once the number of remaining links rea= ches the minimum threshold number. BFD is thus used to decide the fate of an= IP interface. > > We had kept this mode as the default mode. > > I am now having second thoughts on whether this is the right thing to do o= r not. It's a reasonable thing if all you're doing is replacing LACP with BFD as th= e per-leg liveness test; =A0it makes BFD invisible to applications, as the s= ervice interface is the top of the LAG. =A0This is subtly different than hav= ing a BFD-over-the-top session in addition to the individual legs, as doing= so provides visible BFD semantics rather than LAG semantics, and the servic= e interface reflects those semantics (so you can potentially do things like= AdminDown and the like). > > Then there is the second mode described in Section 4. > > Establish BFD sessions over each member link. The aggregate result of this= decides the fate of only the LAG (and not that of the IP interface defined= above it). Establish another BFD session over the LAG (which is what most i= mplementations do today) that runs sedate timers and ensures IP reachability= with the other end. This mode gives us the best of both worlds. > > Would it make more sense to keep this mode as default and completely do aw= ay with the first mode that we have defined? I'm agnostic about the choices; =A0I can see some benefit in both. =A0But th= e real problem is how to do the per-link stuff in a reasonable way. --Dave This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From manav.bhatia@alcatel-lucent.com Thu Dec 15 11:25:31 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 490C121F8AE6 for ; Thu, 15 Dec 2011 11:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USeuM6Ig8rZz for ; Thu, 15 Dec 2011 11:25:28 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 92BD321F8AE1 for ; Thu, 15 Dec 2011 11:25:28 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBFJPLeX005376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Dec 2011 13:25:23 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBFJPK44017095 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Dec 2011 00:55:20 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 16 Dec 2011 00:55:20 +0530 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein Date: Fri, 16 Dec 2011 00:55:19 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7w Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350D026F12ABINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 19:25:31 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350D026F12ABINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, [clipped] Here is my understanding of the problem we try to solve: [clipped] Do these notes capture the problem space correctly? Or did I miss something= important? [Manav] I think this pretty much covers everything One point that is not clear to me is the timeframe for bringing constituent= links of a LAG up. I would expect that the requirements for that could be = much more relaxed (e.g., in order to avoid link flapping). Is that correct?= If it is, one possible implication is that it is possible to use different= mechanisms for bringing links DOWN and UP. To the best of my understanding= , this is how BFD is supposed to be used with routing adjacencies today, i.= e. BFD can bring the adjacency DOWN quite fast, but it has to be brought UP= by the appropriate routing protocol. [Manav] IMO, the member link should come UP as soon as the micro BFD sessi= on gets established. When the entire LAG is shutdown, it will naturally tak= e some more time before it gets ready to take up all traffic as the routing= protocols will take some time before they reconverge (just like how it hap= pens today). When it comes to the solution space, there seem to be several candidates: [clipped] 3. BFD in some special encapsulation: [clipped] [Manav] Agree to all the above points. 4. If LACP is used with the LAG in question, bringing the links UP (a= nd, if necessary, bringing LAG as a whole UP) can be relegated to it. [Manav] I dont understand this part. We bring down the member link when the= micro BFD session goes down. When do we bring that up? Will it not take LA= CP long (at least 1 secs) to bring the link up? There is no need to overload BFD (or any other solution - excluding, of co= urse, faster LACP) with this functionality. This means that IP-based BFD en= capsulations can be safely used as solutions in this case. a. The BFD session using an IP-based encapsulation that has been boun= d to a link in a LAG that went DOWN would wait for LAG coming UP again in o= rder to be restarted. [Manav] I think you meant that the micro BFD session would wait for the mem= ber link to come up before it gets restarted. Why should it wait for the en= tire LAG to come up again? In fact in some cases the LAG will not even go D= OWN when a micro BFD session goes down. b. This scheme seems to eliminate the potential deadlock mentioned by = Manav in his response to Nitin. i. IMHO = and FWIW the approach described by Nitin (a dedicated UDP port) is preferab= le [Manav] If we ensure that the member link is UP before initiating the BFD s= ession then Yes we dont need to use a multicast address and a different UDP= port can be used to disambiguate the BFD packets. This will however not wo= rk for unnumbered IP interfaces. Using a multicast address will work for bo= th numbered and unnumbered IP interfaces. ii. In any= way i suspect that usage of IP encapsulations with multicast IP addresses = would not help: If LAG, as an IP interface, goes down, it may safely discar= d any IP packets it receives [Manav] Good point. 5. If LACP is not used with the LAG in question, a BFD encapsulation = that does not rely on IP/UDP (as proposed by Dave) looks like the only poss= ible solution in this class: a. Once the link-bound session goes DOWN, the BFD state machine trie= s to bring it up again b. Once it is UP, this session indicates to the Aggregator that the li= nk can be used for collection and distribution c. The Aggregator brings UP the LAG as a whole towards MAC clients if= there is enough active constituent links. [Manav] We had ignored this option since we ha dno idea how easy/feasible i= t is to coordinate with IEEE, as one would surely need to do if we chose to= go down this route. Cheers, Manav --_000_7C362EEF9C7896468B36C9B79200D8350D026F12ABINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sasha,
 
[clipped] 

Here=20 is my understanding of the problem we try to solve: 

 

[clipped]

   

Do=20 these notes capture the problem space correctly? Or did I miss something= =20 important? 

 

[M= anav] I think=20 this pretty much covers everything <= /P>

 

One=20 point that is not clear to me is the timeframe for bringing constituen= t=20 links of a LAG up. I would expect that the requirements for that coul= d be=20 much more relaxed (e.g., in order to avoid link flapping). Is that correc= t? If=20 it is, one possible implication is that it is possible to use different=20 mechanisms for bringing links DOWN and UP. To the best of my understandin= g,=20 this is how BFD is supposed to be used with routing adjacencies today, i.= e.=20 BFD can bring the adjacency DOWN quite fast, but it has to be brought UP = by=20 the appropriate routing protocol.

  

[Manav]  IMO, the memb= er=20 link should come UP as soon as the micr= o BFD=20 session gets established. When the entire LAG is shutdown, it will natura= lly=20 take some more time before it gets ready to take up all traffic as the ro= uting=20 protocols will take some time before they reconverge (just like how it ha= ppens=20 today). 

 

<= /o:p>

When=20 it comes to the solution space, there seem to be several candidates: 

  [clipped]

 

 = 3.      = ;=20 BFD=20 in some special encapsulation:

 

[clipped]

 =

[M= anav] Agree=20 to all the above points.

 

4.      = ;=20 If=20 LACP is used with the LAG in question, bringing the links UP (and, if=20 necessary, bringing LAG as a whole UP) can be relegated to it.  

 

[M= anav] I dont=20 understand this part. We bring down the member link when the micro BFD se= ssion=20 goes down. When do we bring that up? Will it not take LACP long (at least= 1=20 secs) to bring the link up?

 

 There is no need to overload BFD = (or any=20 other solution – excluding, of course, faster LACP) with this funct= ionality.=20 This means that IP-based BFD encapsulations can be safely used as solutio= ns in=20 this case.

a.      = ;=20 The=20 BFD session using an IP-based encapsulation that has been bound to a link= in a=20 LAG that went DOWN would wait for LAG coming UP again in order to be=20 restarted. 

 

[Manav] I think you meant that the micro BFD sess= ion=20 would wait for the member link to come up before it gets=20 restarted. Why should it wait for the entire LAG to come up again? I= n=20 fact in some cases the LAG will not even go DOWN when a micro BFD session= goes=20 down.

 

b.     =20 This=20 scheme seems to eliminate the potential deadlock mentioned by Manav in hi= s=20 response to Nitin.

      = ;            &n= bsp;            = ;            &n= bsp;            = ;     =20 i.     =20 IMHO=20 and FWIW the approach described by Nitin (a dedicated UDP port) is=20 preferable  

 

[M= anav] If we=20 ensure that the member link is UP before initiating the BFD session then = Yes=20 we dont need to use a multicast address and a different UDP port can be u= sed=20 to disambiguate the BFD packets. This will however not work for unnumbere= d IP=20 interfaces. Using a multicast address will work for both numbered and=20 unnumbered IP interfaces.

 <= /SPAN>

      = ;            &n= bsp;            = ;            &n= bsp;            = ;   =20 ii.     =20 In=20 any way i suspect that usage of IP encapsulations with multicast IP addre= sses=20 would not help: If LAG, as an IP interface, goes down, it may safely disc= ard=20 any IP packets it receives 

[M= anav] Good=20 point.

 

5.      = ;=20 If=20 LACP is not used with the LAG in question, a BFD encapsulation that does = not=20 rely on IP/UDP (as proposed by Dave) looks like the only possible solutio= n in=20 this class:

a.      = ;=20 Once=20 the link-bound session goes  DOWN, the BFD state machine tries to br= ing=20 it up again

b.     =20 Once=20 it is UP, this session indicates to the Aggregator that the link can be u= sed=20 for collection and distribution

c.      = ;=20 The=20 Aggregator brings UP the LAG as a whole towards MAC clients if there is e= nough=20 active constituent links. 

 

[M= anav] We had=20 ignored this option since we ha dno idea how easy/feasible it=20 is to coordinate with IEEE, as one would surely need to do if w= e=20 chose to go down this route.

 

Ch= eers,=20 Manav

--_000_7C362EEF9C7896468B36C9B79200D8350D026F12ABINBANSXCHMBSA_-- From aldrin.ietf@gmail.com Thu Dec 15 20:17:27 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 2582C11E80BC for ; Thu, 15 Dec 2011 20:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFnu-S-QIlHU for ; Thu, 15 Dec 2011 20:17:26 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 965EF11E80C3 for ; Thu, 15 Dec 2011 20:17:26 -0800 (PST) Received: by ghrr16 with SMTP id r16so2412344ghr.31 for ; Thu, 15 Dec 2011 20:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HV/tg/7WflK99H//4EOyurnHV9Z63zXBLPp6sYt0Jqo=; b=XP9zIvcCv/eNQ1hWo1gSmLFuzZPYRiZpCA/AqT+llA6t3oj1MUTqp/WTlZNkoAECd0 1WKDWlh1mCrw4Y9o7UDA7GtyM66dYptaFpe4iRow/FHMqU3ziAWf8VN/eLVSRzMVFlYJ jEwDOCWvKMBp/KpPyw+S59Ncn1jOyb1vXbctg= MIME-Version: 1.0 Received: by 10.236.173.233 with SMTP id v69mr9223028yhl.46.1324009044804; Thu, 15 Dec 2011 20:17:24 -0800 (PST) Received: by 10.146.139.40 with HTTP; Thu, 15 Dec 2011 20:17:24 -0800 (PST) Date: Thu, 15 Dec 2011 20:17:24 -0800 Message-ID: Subject: BFD MIB extension for MPLS-TP From: Sam Aldrin To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=20cf30562f21cb860604b42de092 Cc: draft-vkst-bfd-mpls-mib@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 04:17:27 -0000 --20cf30562f21cb860604b42de092 Content-Type: text/plain; charset=ISO-8859-1 Hello BFD WG, We have submitted a new draft, BFD MIB extensions to support MPLS-TP, prior to IETF82 at Taipei. The draft is located at http://datatracker.ietf.org/doc/draft-vkst-bfd-mpls-mib/ We have presented the draft in MPLS WG to get feedback from that WG. As there was no WG session at Taipei, we are seeking feedback from BFD WG over the mailing list. The MIB extension is fairly simple and adds few new objects to extend the exiting BFD MIB and support BFD sessions over TP tunnels. Please provide your feedback and comments, so that, we could take it forward and ask to make it a WG document. Appreciate your time. cheers -sam --20cf30562f21cb860604b42de092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello BFD WG,


We have submitted a new draft, BFD MIB extensions to suppor= t MPLS-TP, prior to IETF82 at Taipei.

The draft is located at=A0h= ttp://datatracker.ietf.org/doc/draft-vkst-bfd-mpls-mib/


We have presented the draft in MPLS WG to get feedback from= that WG.

As there was no WG session at Taipei, we are seeking feedba= ck from BFD WG over the mailing list.


The MIB extension is fairly simple and adds few new objects= to extend the exiting BFD MIB and support BFD sessions over TP tunnels.=A0= Please provide your feedback and comments, so that, we could take it forwar= d and ask to make it a WG document.


Appreciate your time.


cheers

-sam

--20cf30562f21cb860604b42de092-- From Alexander.Vainshtein@ecitele.com Thu Dec 15 23:08:20 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 E9DE221F8562 for ; Thu, 15 Dec 2011 23:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.577 X-Spam-Level: X-Spam-Status: No, score=-4.577 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5orRKhzzLpH for ; Thu, 15 Dec 2011 23:08:19 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 731EE21F8548 for ; Thu, 15 Dec 2011 23:08:18 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1324019251!49242742!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 9948 invoked from network); 16 Dec 2011 07:07:31 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-3.tower-27.messagelabs.com with SMTP; 16 Dec 2011 07:07:31 -0000 X-AuditID: 93eaf2e8-b7f276d000000ac3-8d-4eeaef6ba280 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id EC.60.02755.B6FEAEE4; Fri, 16 Dec 2011 09:12:43 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Fri, 16 Dec 2011 09:08:14 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Fri, 16 Dec 2011 09:08:15 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7wABf3ME0= Message-ID: References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76011248A1E699ILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0gUURjtzsyuozk1rdpe7cE0UZKxufYAe2xFIBX0sqKgoJp2brtTuzPL zKxkBa09CI3IlIwssodZqGRamaRGbgQ9zILKR48tKnpsiaVRFKHNOGb+6d+555zvO9+d+S6J W/IiEkhBVJEsch7WHEXkhzu/2bZ0hJfYa0unph4PhUypXb+rwVxswd539aYFxcU/sWXYmgCY xYmipHIqYnikOB3sMlnI4JyZLCPwDjaFZXwezom8SFQdLOfzIZFnZ0fN0khBZJDolHhBdDnY hSuW2lJTp023pbCzx49NmTIzaqVbUBhk83KCh/EiReFciNEYfUKRRzyzSZIZ1Y0YeUM+7n5U VmD2vSvFtj7+fo4IgNoAlgMiSUhPhVktF4GBh8OHoQpzDogiLXQtgM1NZzDjUABg9qv9Jt1l ph2wquyFWcexGn5/6Rqhm3C6G8CGA4EIXSDocbD5YluvKYZmYWnurwijYCy8+uIlMPAMePtY dS9P0emw6kJlX/QZACtvduG6EEmvg1m/W3obAW2+H3fLe+fGaSt8+rao7w40LK57gBs4Dn58 020y/HHw+b4KYPgl+KR9j9kIGwbvHH1LGP542HC+lcgFwwsHtC0cUFI4oMTg7bCjqQg38ERY cupTH06Gld/ug4H8SRBRCuIFj0/d6HXZJ9skvzoJOQUVedAkp+StAsYSfagBzxonBAFNAjaa CvDhJRYTl6FkeoMgnsTYOOpIu0YN2SjxmW5Oca+X/R6kBAEkcTaWss7RNIrnMrchWforpWm/ 4BCeMNgp6cugrp9it///wFqp/c7Piy20S1vRLQj5kPy3z0iSZCFVpMcPk5ELbd0keNR/MkZG 6mNEa2PU6x5K8XFeRXAZ+l1gI+u7fjQCCyFKIkqwUpd1E62b3H6xv4/+lHb29PSEgVX7ADFU ne6K1ta4v1NYC8G0kKurPugh2lPqlxICIHl1SdqY57XX3OWJZ337OssONuS0ZvGjMLnrFdGU FAzdrssrXLHn9KDgjuztBXCdwFV0H54n0/7Qomkj5l+vfnaC77zyeM0X0bM7995pk2WodONy 8spbR9KDsV9ftrdtq/HnN6ox5errmI7m74m27NFtwsjg4Z7Ny627ycETXGt3sYTi5lKScFnh /gCaFuCmJQQAAA== Cc: Jagrati Shringi , Manish Vora , John Shirron , Oren Gal , "rtg-bfd@ietf.org" , Robert Rennison X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 07:08:21 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011248A1E699ILPTMAIL02e_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Hi Manav, Lots of thanks for a prompt and detailed response. Before I go into specifics, I have a couple of terminological comments: 1. I've assumed that what you call LMM in the draft is called "Aggregator"= in the IEEE 802 parlance. Is this correct? (Aside: IMHO it is important to= map the problem and solution to IEEE 802 notions and terms, especially if a= ny form of coordination/synchronization with this body is expected/required)= . 2. I assume that your "micro-BFD session" is what I have called "a BFD ses= sion bound to a specific constituent link of the LAG". I will use your term= since it is much shorter. Now is the time for specific responses to your comments. 1. You've said that the member link should come UP as soon as the micro BF= D session gets established and, based on this, you reject LACP (if used) as= the mechanism for bringing the member link UP - Will it not take LACP long= (at least 1 secs) to bring the link up? I see two issues with this logic: * Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD= control packet per second (as explained in RFC 5880, Section 6.8.3). Hence= I would expect that bringing UP a failed member link via the 5880-compliant= micro-BFD session would take approximately as long as it would with LACP us= ing a 1' timer. Or do you worry about LACP with 30' timers? * If LACP is used on a LAG member that has been brought DOWN by a micr= o-BFD session, it has to be involved i bringing the link UP anyway: it must= declare the local link state as "Collecting" and then go thru some stages u= ntil the link is recognized as "Collecting" and "Distributing" by both peers= . This would also take some time (probably a few hundreds of milliseconds) b= ecause LACP is a slow protocol. Attempts to bypass the LACP procedures for b= ringing the link UP could easily run into serious interoperability problems= - unless you are ready to say that LAG with LACP and LAG with per-link BFD= are mutually exclusive. 2. Which entity should activate the micro-BFD session, and when? I've prob= ably not expressed my position clearly enough, hence your comment I think y= ou meant that the micro BFD session would wait for the member link to come u= p before it gets restarted. Why should it wait for the entire LAG to come up= again? In fact in some cases the LAG will not even go DOWN when a micro BFD= session goes down. What I've really meant is the following: * If micro-BFD sessions use IP-based encapsulations, LAG (which is the= interface that IP sees) MUST be UP before they can be activated. As I've no= ted, if LAG is down it could safely drop any IP packets it receives. You see= m to have accepted this point. * If LACP is used on LAG members and micro-BFD sessions do not use IP-= based encapsulation, they can be activated once LACP brings the link UP. * BFD sessions that do not use IP encapsulation can be used even if LA= CP is not used on LAG members. In this case they will interact directly with= the Aggregator rather than with LACP. 3. You've claimed that an IP-based encapsulation for micro-BFD that uses u= nicast IP destination address and a dedicated UDP port (to differentiate it= from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP inter= faces. I think that this is incorrect because RFC 5881 works for unnumbered= P2P IP interfaces as fine as for numbered ones. The relevant text is IMHO i= n Section 6 "Addressing issues" of RFC 5881, and the only part of it that is= relevant to P2P links says that "the source address of a BFD Control packet= MUST NOT be used to identify the session". 4. Last but not least, I do not think that my proposals require complicate= d coordination with IEEE 802.1AX. LAG-related state machines are well define= d, all you need is feeding existing some inputs into them from micro-BFD rat= her than from the physical layer, and activating micro-BFD sessions from the= m (which is a minor change IMO). However, to this extent coordination with I= EEE 802.1AX seems unavoidable unless you explicitly declare that LAG with m= icro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.= 1AX - and bear all the consequences of such a decision. My 2c, Sasha ________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Thursday, December 15, 2011 9:25 PM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Hi Sasha, [clipped] Here is my understanding of the problem we try to solve: [clipped] Do these notes capture the problem space correctly? Or did I miss something= important? [Manav] I think this pretty much covers everything One point that is not clear to me is the timeframe for bringing constituent= links of a LAG up. I would expect that the requirements for that could be m= uch more relaxed (e.g., in order to avoid link flapping). Is that correct? I= f it is, one possible implication is that it is possible to use different me= chanisms for bringing links DOWN and UP. To the best of my understanding, th= is is how BFD is supposed to be used with routing adjacencies today, i.e. BF= D can bring the adjacency DOWN quite fast, but it has to be brought UP by th= e appropriate routing protocol. [Manav] IMO, the member link should come UP as soon as the micro BFD sessio= n gets established. When the entire LAG is shutdown, it will naturally take= some more time before it gets ready to take up all traffic as the routing p= rotocols will take some time before they reconverge (just like how it happen= s today). When it comes to the solution space, there seem to be several candidates: [clipped] 3. BFD in some special encapsulation: [clipped] [Manav] Agree to all the above points. 4. If LACP is used with the LAG in question, bringing the links UP (an= d, if necessary, bringing LAG as a whole UP) can be relegated to it. [Manav] I dont understand this part. We bring down the member link when the= micro BFD session goes down. When do we bring that up? Will it not take LAC= P long (at least 1 secs) to bring the link up? There is no need to overload BFD (or any other solution =96 excluding, of c= ourse, faster LACP) with this functionality. This means that IP-based BFD en= capsulations can be safely used as solutions in this case. a. The BFD session using an IP-based encapsulation that has been bound= to a link in a LAG that went DOWN would wait for LAG coming UP again in ord= er to be restarted. [Manav] I think you meant that the micro BFD session would wait for the memb= er link to come up before it gets restarted. Why should it wait for the enti= re LAG to come up again? In fact in some cases the LAG will not even go DOWN= when a micro BFD session goes down. b. This scheme seems to eliminate the potential deadlock mentioned by M= anav in his response to Nitin. i. IMHO a= nd FWIW the approach described by Nitin (a dedicated UDP port) is preferable [Manav] If we ensure that the member link is UP before initiating the BFD se= ssion then Yes we dont need to use a multicast address and a different UDP p= ort can be used to disambiguate the BFD packets. This will however not work= for unnumbered IP interfaces. Using a multicast address will work for both= numbered and unnumbered IP interfaces. ii. In any= way i suspect that usage of IP encapsulations with multicast IP addresses w= ould not help: If LAG, as an IP interface, goes down, it may safely discard= any IP packets it receives [Manav] Good point. 5. If LACP is not used with the LAG in question, a BFD encapsulation t= hat does not rely on IP/UDP (as proposed by Dave) looks like the only possib= le solution in this class: a. Once the link-bound session goes DOWN, the BFD state machine tries= to bring it up again b. Once it is UP, this session indicates to the Aggregator that the lin= k can be used for collection and distribution c. The Aggregator brings UP the LAG as a whole towards MAC clients if= there is enough active constituent links. [Manav] We had ignored this option since we ha dno idea how easy/feasible it= is to coordinate with IEEE, as one would surely need to do if we chose to g= o down this route. Cheers, Manav This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76011248A1E699ILPTMAIL02e_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable
Hi Manav,
Lots of thanks for a prompt and detailed= response.
 
Before I go into specifics, I have a cou= ple of terminological comments:
  1. I've assumed that what you call LMM in th= e draft is called "Aggregator" in the IEEE 802 parlance. Is this c= orrect? (Aside: IMHO it is important to map the problem and solution to IEEE= 802 notions and terms, especially if any form of coordination/synchronization with this body is expected/required).<= /font>
  2. I assume that your "micro-BFD s= ession" is what I have called "a BFD session bound to a specific c= onstituent link of the LAG". I will use your term since it is much shor= ter.

 

Now is the time for specific responses to your comments.

 

  1. You've said that the member link should come UP as soon as= the micro BFD session gets established and, based on t= his, you reject LACP (if used) as the mechanism for bringing the member= link UP - Will it not take LACP long (at least 1 secs) to bring the l= ink up? I see two issues with this logic:
    • Once the micro-BFD session goes DOWN, it= falls back to sending 1 BFD control packet per second (as explained in RFC= 5880, Section 6.8.3). Hence I would expect that bringing UP a failed member= link via the 5880-compliant micro-BFD session would take approximately as long as it would with LACP using a 1' t= imer. Or do you worry about LACP with 30' timers?
    • If LACP is used on a LAG member that= has been brought DOWN by a micro-BFD session, it has to be involved i<= a> bringing the link UP anyway: it must declare the local= link state as "Collecting" and then go thru some stages until the link is recognized as "Collecting" and &quo= t;Distributing" by both peers. This would also take some time (probably= a few hundreds of milliseconds) because LACP is a slow protocol. Attempts t= o bypass the LACP procedures for bringing the link UP could easily run into serious interoperability problems - unless you are= ready to say that LAG with LACP and LAG with per-link BFD are mutually excl= usive.
  2. Which entity should activate the mic= ro-BFD session, and when? I've probably not expressed my position clearly en= ough, hence your comment  I think you meant that the micro BFD session would wait for the member link to come up before it gets restarted.&nb= sp;Why should it wait for the entire LAG to come up again? In fact in some c= ases the LAG will not even go DOWN when a micro BFD session goes down. What I've really meant is the following:
    • If micro-BFD sessions use IP-based en= capsulations, LAG (which is the interface that IP sees) MUST be UP befo= re they can be activated. As I've noted, if LAG is down it could safely drop= any IP packets it receives. You seem to have accepted this point.
    • If LACP is used on LAG members and micro-BFD sessions do not use IP-ba= sed encapsulation, they can be activated once LACP brings the link UP.
    • BFD sessions that do not use= IP encapsulation can be used even if LACP is not used on LAG members. In this case they will interact directly with the Aggregator rather than= with LACP.
  3. You've claimed that an IP-based enca= psulation for micro-BFD that uses unicast IP desti= nation address and a dedicated UDP port (to differentiate it from a 1-hop IP= v4/IPv6 session) would will not work for unnumber= ed IP interfaces. I think that this is incorrect because RFC 5881 wor= ks for unnumbered P2P IP interfaces as fine as for numbered ones.= The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is= relevant to P2P links says that "the source address of a BFD Control packet MUST NOT= be used to identify the session".
  4. Last but not least, I do not think t= hat my proposals require complicated coordination with IEEE 802.1AX. LAG-rel= ated state machines are well defined, all you need is feeding existing some= inputs into them from micro-BFD rather than from the physical layer, and activating micro-BFD sessions from them (= which is a minor change IMO). However, to this extent coordination= with IEEE 802.1AX  seems unavoidable unless you explicitly declare tha= t LAG with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the consequences of= such a decision.

My 2c,

     Sasha

 
 
 
From: Bhatia, Mana= v (Manav) [manav.bhatia@alcatel-lucent.com]
Sent: Thursday, December 15, 2011 9:25 PM
To: Alexander Vainshtein
Cc: rtg-bfd@ietf.org
Subject: RE: BFD on LAG interfaces

Hi Sasha,
 
[clipped] 

Here is my understanding of the problem we try to solve: 

 

[clipped]

   

Do these notes capture the problem space cor= rectly? Or did I miss something important? 

 

[Manav] I think this pretty much co= vers everything 

 

One point that is not clear to me is the timeframe for bringing constituent links of a LAG up. I would exp= ect that the requirements for that could be much more relaxed (e.g., in orde= r to avoid link flapping). Is that correct? If it is, one possible implicati= on is that it is possible to use different mechanisms for bringing links DOWN and UP. To the best of my= understanding, this is how BFD is supposed to be used with routing adjacenc= ies today, i.e. BFD can bring the adjacency DOWN quite fast, but it has to b= e brought UP by the appropriate routing protocol.

  

[Manav]  IMO, the member link should come UP as soon as the mic= ro BFD session gets established. When the entire LAG is shutdown, it will na= turally take some more time before it gets ready to take up all traffic as t= he routing protocols will take some time before they reconverge (just like how it happens today). 

 

When it comes to the solution space, there s= eem to be several candidates: 

  [clipped]

 

 3= .     &= nbsp; BFD in some specia= l encapsulation:

 

[clipped]

 

[Manav] Agree to all the above points.

 

4.=      &n= bsp; If LACP is used with= the LAG in question, bringing the links UP (and, if necessary, bringing LAG= as a whole UP) can be relegated to it.  

 

[Manav] I dont understand this part. We bring down the member link when the micro BFD session goes down. When do we bring= that up? Will it not take LACP long (at least 1 secs) to bring the link up?

 

 There is no need to overload BFD (or= any other solution =96 excluding, of course, faster LACP) with this functionality. This means that IP-based BFD encapsul= ations can be safely used as solutions in this case.

a.  &= nbsp;    The BFD session using= an IP-based encapsulation that has been bound to a link in a LAG that went= DOWN would wait for LAG coming UP again in order to be restarted. 

 

[Manav] I think you meant that the micro BFD session would wait for the member link to come= up before it gets restarted. Why should it wait for the entire LAG to= come up again? In fact in some cases the LAG will not even go DOWN when a m= icro BFD session goes down.

 

b.  &= nbsp;   This scheme seems to= eliminate the potential deadlock mentioned by Manav in his response to Niti= n.

  &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;         i.    = ;  IMHO and FWIW= the approach described by Nitin (a dedicated UDP port) is preferable <= span class=3D"930524318-15122011"> 

 

[Manav] If we ensure that the member link is UP before initiating the BFD session then Yes we do= nt need to use a multicast address and a different UDP port can be used to d= isambiguate the BFD packets. This will however not work for unnumbered IP in= terfaces. Using a multicast address will work for both numbered and unnumbered IP interfaces.

 

  &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;       ii.   &nbs= p;  In any way i= suspect that usage of IP encapsulations with multicast IP addresses would not help: If LAG, as an IP interface, goes down, it may safely discar= d any IP packets it receives 

[Manav] Good point.

 

5.=      &n= bsp; If LACP is not used w= ith the LAG in question, a BFD encapsulation that does not rely on IP/UDP (a= s proposed by Dave) looks like the only possible solution in this class:

a.  &= nbsp;    Once the link-bound s= ession goes  DOWN, the BFD state machine tries to bring it up again

b.  &= nbsp;   Once it is UP, this s= ession indicates to the Aggregator that the link can be used for collection= and distribution

c.  &= nbsp;    The Aggregator brings= UP the LAG as a whole towards MAC clients if there is enough active constit= uent links. 

 

[Manav] We had ignored this option since we ha dno idea how easy/feasible it is to= coordinate with IEEE, as one would surely need to do if we chose to go= down this route.

 

Cheers, Manav

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76011248A1E699ILPTMAIL02e_-- From manav.bhatia@alcatel-lucent.com Fri Dec 16 00:29:09 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 5835A21F8AEA for ; Fri, 16 Dec 2011 00:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIuXxO6JYpJw for ; Fri, 16 Dec 2011 00:29:08 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id EE65F21F8AE9 for ; Fri, 16 Dec 2011 00:29:07 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pBG8T2au012438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2011 02:29:04 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBG8T1Ow024960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Dec 2011 13:59:01 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 16 Dec 2011 13:59:01 +0530 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein Date: Fri, 16 Dec 2011 13:59:00 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7wABf3ME0AA9Aj4A== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350D026F132FINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 08:29:09 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350D026F132FINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, Thanks for your comments. My response's inline. Before I go into specifics, I have a couple of terminological comments: 1. I've assumed that what you call LMM in the draft is called "Aggregator= " in the IEEE 802 parlance. Is this correct? (Aside: IMHO it is important t= o map the problem and solution to IEEE 802 notions and terms, especially if= any form of coordination/synchronization with this body is expected/requir= ed). 2. I assume that your "micro-BFD session" is what I have called "a BFD se= ssion bound to a specific constituent link of the LAG". I will use your ter= m since it is much shorter. [Manav] Yes, to both. I like the term "micro-BFD session" since it easily h= elps in distinguishing between the two different BFD flavors. You've said that the member link should come UP as soon as the micro BFD s= ession gets established and, based on this, you reject LACP (if used) as th= e mechanism for bringing the member link UP - Will it not take LACP long (a= t least 1 secs) to bring the link up? I see two issues with this logic: * Once the micro-BFD session goes DOWN, it falls back to sending 1 BF= D control packet per second (as explained in RFC 5880, Section 6.8.3). Henc= e I would expect that bringing UP a failed member link via the 5880-complia= nt micro-BFD session would take approximately as long as it would with LACP= using a 1' timer. Or do you worry about LACP with 30' timers? * 1. [Manav] If LACP uses its default periodic timer of 30 secs, then that = screws up BFD. This means that BFD on LAG will only work if the administrat= or manually changes the default LACP timer from 30s to 1sec. I am not very = comfortable with a solution that hinges on all administrators manually conf= iguring something correctly for it to work - to me this is a very tenuous d= esign. [Manav] This also necessitates running LACP along with BFD. I am = ok if LACP can run with BFD. I am not sure if i am ok with mandating LACP t= o run with BFD. But then this is a personal choice .. 1. * If LACP is used on a LAG member that has been brought DOWN by a mic= ro-BFD session, it has to be involved i bringing the link UP anyway: it mus= t declare the local link state as "Collecting" and then go thru some stages= until the link is recognized as "Collecting" and "Distributing" by both pe= ers. This would also take some time (probably a few hundreds of millisecond= s) because LACP is a slow protocol. Attempts to bypass the LACP procedures = for bringing the link UP could easily run into serious interoperability pro= blems - unless you are ready to say that LAG with LACP and LAG with per-lin= k BFD are mutually exclusive. * Which entity should activate the micro-BFD session, and when? I've probably= not expressed my position clearly enough, hence your comment I think you = meant that the micro BFD session would wait for the member link to come up = before it gets restarted. Why should it wait for the entire LAG to come up = again? In fact in some cases the LAG will not even go DOWN when a micro BFD= session goes down. What I've really meant is the following: 1. * If micro-BFD sessions use IP-based encapsulations, LAG (which is th= e interface that IP sees) MUST be UP before they can be activated. As I've = noted, if LAG is down it could safely drop any IP packets it receives. You = seem to have accepted this point. [Manav] LAG can only be UP, if there is atleast one component link that is = alive. Yes what you have described is a deadlock. But this is more so with = Unicast encapsulation. With multicast, we could say that just as a port tha= t is down processes certain L2 control frames, it should also process frame= s coming with a well known IANA allocated multicast MAC (which would be use= d by all micro-BFD sessions). If we were to go with a unicast IP encapsulat= ion, then we will have to let the port that is down accept (i) all broadcas= t frames (ARP requests) (ii) all packets coming with your own MAC (ARP repl= ies) (iii) all IP packets addressed to you. Clearly, this is an order of magnitude worse than what happens if = we go with multicast IP encapsulation. 1. * If LACP is used on LAG members and micro-BFD sessions do not use IP= -based encapsulation, they can be activated once LACP brings the link UP. [Manav] Yes. I think i had mentioned even earlier that BFD without IP based= encapsulation is perhaps the best. But that requires a well known MAC from= IEEE and a new Ether type. I am not sure how easy or complex this is. * BFD sessions that do not use IP encapsulation can be used even if L= ACP is not used on LAG members. In this case they will interact directly wi= th the Aggregator rather than with LACP. 2. 3. [Manav] I am not sure i understand why having an IP encapsulation prec= ludes an implementation to directly interact with the Aggregator. In fact, = all control packets from the micro BFD session will ONLY interact with the = Aggregator, and never with LACP. 4. 5. You've claimed that an IP-based encapsulation for micro-BFD that uses = unicast IP destination address and a dedicated UDP port (to differentiate i= t from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP int= erfaces. I think that this is incorrect because RFC 5881 works for unnumber= ed P2P IP interfaces as fine as for numbered ones. The relevant text is IMH= O in Section 6 "Addressing issues" of RFC 5881, and the only part of it tha= t is relevant to P2P links says that "the source address of a BFD Control p= acket MUST NOT be used to identify the session". [Manav] I am more concerned about the destination IP address than the sourc= e IP. What dest IP to you use? Even if you do manage to use a 127/8, what d= est MAC do you use? Do you use a well known L2 MAC address for IP unicast b= ased encaps. If Yes, then you need to get this from IEEE. Note that with multicast you dont need any L2 address allocation. 1. Last but not least, I do not think that my proposals require complicat= ed coordination with IEEE 802.1AX. LAG-related state machines are well defi= ned, all you need is feeding existing some inputs into them from micro-BFD = rather than from the physical layer, and activating micro-BFD sessions from= them (which is a minor change IMO). However, to this extent coordination w= ith IEEE 802.1AX seems unavoidable unless you explicitly declare that LAG = with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023= ad/802.1AX - and bear all the consequences of such a decision. [Manav] I am not worried about feeding state from the micro BFD sessions to= the LAG module - thats an implementation specific issue. What i am concern= ed about is getting their approval for a new ether type, L2 mac addr and ne= w encap that we want. Cheers, Manav --_000_7C362EEF9C7896468B36C9B79200D8350D026F132FINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sasha,
 
Thanks for your comments.
 
My response's inline.
 
Before I go into= specifics,=20 I have a couple of terminological comments:
  1. I've assumed that what you call LMM = in the=20 draft is called "Aggregator" in the IEEE 802 parlance. Is this correct?= =20 (Aside: IMHO it is important to map the problem and solution to IEEE 80= 2=20 notions and terms, especially if any form of coordination/synchronizati= on=20 with this body is expected/required).=20
  2. I assume that your "micro-BFD sessio= n" is=20 what I have called "a BFD session bound to a specific constituent link = of=20 the LAG". I will use your term since it is much shorter. 
 
[Manav] Yes, to both. I like the term "mi= cro-BFD=20 session" since it easily helps in distinguishing between t= he=20 two different BFD flavors.

 

 You've said that the member=20 link should come UP as soon as t= he micro=20 BFD session gets established and, based on this,=20 you reject LACP (if used) as the mechanism for bringing the member l= ink=20 UP - Will it not take LA= CP long (at=20 least 1 secs) to bring the link up? I see two= =20 issues with this logic:

    • Once the micro-BFD session goes DO= WN, it=20 falls back to sending 1 BFD control packet per second (as explained i= n RFC=20 5880, Section 6.8.3). Hence I would expect that bringing UP a failed= =20 member link via the 5880-compliant micro-BFD session would take=20 approximately as long as it would with LACP using a 1' timer. Or= =20 do you worry about LACP with 30' timers?  
  1. = [Manav] If=20 LACP uses its default periodic timer of 30 secs, then that screws = up=20 BFD. This means that BFD on LAG will only work if the=20 administrator manually changes the default LACP timer from 30s to = 1sec.=20 I am not very comfortable with a solution that hinges on all administra= tors=20 manually configuring something correctly for it to work - to me this is= a=20 very tenuous design.
 
          [Manav] T= his=20 also necessitates running LACP along with BFD. I am ok if LACP can run wi= th=20 BFD. I am not sure if i am ok with mandating LACP to run with BFD. But th= en=20 this is a personal choice ..
    • If LACP is used on a LAG member th= at has=20 been brought DOWN by a micro-BFD session, it has to be=20 involved i bringing the link UP anyway: it = must=20 declare the local link state as "Collecting" and then go thru some st= ages=20 until the link is recognized as "Collecting" and "Distributing" by bo= th=20 peers. This would also take some time (probably a few hundreds of=20 milliseconds) because LACP is a slow protocol. Attempts to bypass the= LACP=20 procedures for bringing the link UP could easily run into serious=20 interoperability problems - unless you are ready to say that LAG with= LACP=20 and LAG with per-link BFD are mutually exclusive. 
Which entity should activate the micr= o-BFD=20 session, and when? I've probably not expressed my position clearly enough= ,=20 hence your comment  I think you meant that the micro BFD session wou= ld wait=20 for the member link to come up before it gets restarted. Why sh= ould=20 it wait for the entire LAG to come up again? In fact in some cases the LA= G=20 will not even go DOWN when a micro BFD session goes down. What I'v= e=20 really meant is the following:
    • If micro-BFD sessions use IP-b= ased=20 encapsulations, LAG (which is the interface that IP sees) MUST b= e UP=20 before they can be activated. As I've noted, if LAG is down it could= =20 safely drop any IP packets it receives. You seem to have accepted thi= s=20 point.  
     
    [Manav] LAG can only be UP, if there is atleast one compo= nent=20 link that is alive. Yes what you have described is a deadlock. But= this=20 is more so with Unicast encapsulation. With multicast, we could say tha= t=20 just as a port that is down processes certain L2 control frames, i= t=20 should also process frames coming with a well known IANA allocated mult= icast=20 MAC (which would be used by all micro-BFD sessions). If we were to go w= ith a=20 unicast IP encapsulation, then we will have to let the port that is dow= n=20 accept (i) all broadcast frames (ARP requests) (ii) all packets coming = with=20 your own MAC (ARP replies) (iii) all IP packets addressed to=20 you.
 
       &nbs= p;=20 Clearly, this is an order of = magnitude=20 worse than what happens if we go with multicast IP=20 encapsulation.
    • If LACP is used on LAG members and= =20 micro-BFD sessions do not use IP-based encapsulation, they can be=20 activated once LACP brings the link UP.  
     
    [Manav] Yes. I think i had mentioned even ea= rlier=20 that BFD without IP based encapsulation is perhaps the best. But that=20 requires a well known MAC from IEEE and a new Ether type. I am not sure= how=20 easy or complex this is.
     
    • BFD sessions that do not use IP=20 encapsulation can be used even if LACP is not used on LAG members. In=20 this case they will interact directly with the Aggregator rather than= with=20 LACP. 
  3. [Manav] I am not sure i understand why havin= g an IP=20 encapsulation precludes an implementation to directly interact with the= =20 Aggregator. In fact, all control packets from the micro BFD session wil= l=20 ONLY interact with the Aggregator, and never with LACP.
  4.      =
  5. You've claimed that an IP-based=20 encapsulation for micro-BFD that uses unicast= IP=20 destination address and a dedicated UDP port (to differentiate it from = a=20 1-hop IPv4/IPv6 session) would will=20 not work for unnumbered IP interfaces. I think that this is inco= rrect=20 because RFC 5881 works for unnumbered P2P IP interfaces as fine as= for=20 numbered ones. The relevant text is IMHO in Section 6=20 "Addressing issues" of RFC 5881, and the only part of it that is releva= nt to=20 P2P links says that "the source address of a BFD Control packet MUST NOT be= used=20 to identify the session".  
 
[Manav] I am more concerned about the destination IP a= ddress=20 than the source IP. What dest IP to you use? Even if you do manage t= o use=20 a 127/8, what dest MAC do you use? Do you use a well known L2 MAC address= for=20 IP unicast based encaps. If Yes, then you need to get this from=20 IEEE.
 
Note=20 that with multicast you dont need any L2 address=20 allocation. 
  1. Last but not least, I do not think t= hat my=20 proposals require complicated coordination with IEEE 802.1AX. LAG-relat= ed=20 state machines are well defined, all you need is feeding existing some= =20 inputs into them from micro-BFD rather than from the physic= al=20 layer, and activating micro-BFD sessions from them (which is = a=20 minor change IMO). However, to this extent coordination with IEEE= =20 802.1AX  seems unavoidable unless you explicitly declare that LAG = with=20 micro-BFD sessions is mutually exclusive with one defined by IEEE=20 8023ad/802.1AX - and bear all the consequences of such a=20 decision.  
 
[Manav] I am not worried about feeding st= ate=20 from the micro BFD sessions to the LAG module - thats an implementation=20 specific issue. What i am concerned about is getting their approval for a= new=20 ether type, L2 mac addr and new encap that we want.  <= /DIV>
 
Cheers,=20 Manav
--_000_7C362EEF9C7896468B36C9B79200D8350D026F132FINBANSXCHMBSA_-- From Alexander.Vainshtein@ecitele.com Fri Dec 16 03:12:45 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 4875C21F8B08 for ; Fri, 16 Dec 2011 03:12:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEr9TFAE38WI for ; Fri, 16 Dec 2011 03:12:44 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 217A521F8A62 for ; Fri, 16 Dec 2011 03:12:42 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1324033960!7723793!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 8174 invoked from network); 16 Dec 2011 11:12:41 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-216.messagelabs.com with SMTP; 16 Dec 2011 11:12:41 -0000 X-AuditID: 93eaf2e8-b7f276d000000ac3-72-4eeb28b40004 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 4F.43.02755.4B82BEE4; Fri, 16 Dec 2011 13:17:08 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 16 Dec 2011 13:12:39 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Fri, 16 Dec 2011 13:12:39 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7wABf3ME0AA9Aj4AAGKKfi Message-ID: References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69BILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTb0wTZxzmvbu2B+PMUURecIu31xQVLFL/JHVS3Ae3sUTRRWOCycbO3mt7 s71r7g4jy4zNptHAWMpgmzYmc0lDCJCQyBQBa1yzJY40m8MPIsMumwQ7KomKm2GbZXecMr7s 2/P+nud9nid3v5cm7W22UlqUNKxIfABZ86j26UePnV+vzdRVzTQj97lUyuKe/ecSeJWoPTkV t9TGYnPEHuJAGFTzkiRrvIY5AateD9qjiEd4bxPiRMGDXIgLBXgvDmJJ8yA+FMKSgGryqvWh KHFY8sqCKPk86M29u51u95atTheqKVvt2rQtb59fVDnsDPJigAtiVeV9mNMnRkNJwAJ3SFY4 zY855d120p/8tBmETk+Ao90Dk2QYpAdBM8ilIbsZZuZOECZeAW+k+qzNII+2s4MAPuycIsxD B4BXR361Gior64EXeu4s4OU6vtc/RBmYZNfBD6/P2gxMsQ54+6PkQkIhi2B35C+bqV8NB+78 Akz8OozG71oMzLBvwc6pQdIMixOw56fvFkxz2Xdgx9P2hTCg13sy0kuYYcVwfPLLZ7VZGLvy I2niIvj73azF1BfBiVN9wNTL8N6DXsoMK4Dfn52kTH0J/KZrjIqAFdElttElV6JLrpjzSjj2 WYfVxBWw86sMaWInPJNNUEvn54GtG5SIgZB2MOir2uiUG7VK7BU1HMCVXjl4AZg7lL4Mfk6u SwCWBiifCQvTdXYLf0RtCiZACU2gIiblyNTZlx2UhSY/r/oblMYAVhMA0iRaznRROscIfNP7 WJGfU6/pv6CNLH3BKxu7oDVsqqr6/wMqZlq893fZWZ++oYcxDmHluc+LNI0gM1qmRxQo2IeP HhID2n80QecaNfL1Gn8aGkYN8UFV9Jn8CHDS8dknSWCnJFnCpcXMhCFiDZG/UVr0MV7S8fn5 +WlQrH+AQmbIUOXrW7zoNK2HEHrIwP60EaK/pEWqNAz6z7eMuz4fxkO9rTCbbd0YiR/veKmi 4T3L4eGnn/Tk7KxJr+ysiNT87fONV7zszNwofNx68dv++ljqjZzWM9EPpDUPmIdf7Ki+nyOd feVRwj14a3vLH6Obz12bKb95PRt2ON627ez6Lfqx+4eeDfW1sbk+x2zDqkj5svSx6i3JDTNt 6xGl+nlXOamo/L/959pnJAQAAA== Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 11:12:45 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69BILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Manav, Lots of thanks for a prompt response. Please see some comments inline in green italics below (with snipped parts= when we seem to be aligned). Regards, Sasha ________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Friday, December 16, 2011 10:29 AM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Hi Sasha, Thanks for your comments. My response's inline. ... snipped... You've said that the member link should come UP as soon as the micro BFD se= ssion gets established and, based on this, you reject LACP (if used) as the= mechanism for bringing the member link UP - Will it not take LACP long (at= least 1 secs) to bring the link up? I see two issues with this logic: * Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD= control packet per second (as explained in RFC 5880, Section 6.8.3). Hence= I would expect that bringing UP a failed member link via the 5880-compliant= micro-BFD session would take approximately as long as it would with LACP us= ing a 1' timer. Or do you worry about LACP with 30' timers? * 1. [Manav] If LACP uses its default periodic timer of 30 secs, then that s= crews up BFD. This means that BFD on LAG will only work if the administrator= manually changes the default LACP timer from 30s to 1sec. I am not very com= fortable with a solution that hinges on all administrators manually configur= ing something correctly for it to work - to me this is a very tenuous design= . [[Sasha]] I see your point, but I do not think it is a very serious issue. M= isconfiguration can kill lots of protocols, and BFD is not really an excepti= on. [Manav] This also necessitates running LACP along with BFD. I am o= k if LACP can run with BFD. I am not sure if i am ok with mandating LACP to= run with BFD. But then this is a personal choice .. [[Sasha]] LACP is only required if you insist on running BFD in an IP encaps= ulation. 1. * If LACP is used on a LAG member that has been brought DOWN by a micr= o-BFD session, it has to be involved i bringing the link UP anyway: it must= declare the local link state as "Collecting" and then go thru some stages u= ntil the link is recognized as "Collecting" and "Distributing" by both peers= . This would also take some time (probably a few hundreds of milliseconds) b= ecause LACP is a slow protocol. Attempts to bypass the LACP procedures for b= ringing the link UP could easily run into serious interoperability problems= - unless you are ready to say that LAG with LACP and LAG with per-link BFD= are mutually exclusive. * Which entity should activate the micro-BFD session, and when? I've probably= not expressed my position clearly enough, hence your comment I think you m= eant that the micro BFD session would wait for the member link to come up be= fore it gets restarted. Why should it wait for the entire LAG to come up aga= in? In fact in some cases the LAG will not even go DOWN when a micro BFD ses= sion goes down. What I've really meant is the following: 1. * If micro-BFD sessions use IP-based encapsulations, LAG (which is the= interface that IP sees) MUST be UP before they can be activated. As I've no= ted, if LAG is down it could safely drop any IP packets it receives. You see= m to have accepted this point. [Manav] LAG can only be UP, if there is atleast one component link that is a= live. Yes what you have described is a deadlock. But this is more so with Un= icast encapsulation. With multicast, we could say that just as a port that i= s down processes certain L2 control frames, it should also process frames co= ming with a well known IANA allocated multicast MAC (which would be used by= all micro-BFD sessions). If we were to go with a unicast IP encapsulation,= then we will have to let the port that is down accept (i) all broadcast fra= mes (ARP requests) (ii) all packets coming with your own MAC (ARP replies) (= iii) all IP packets addressed to you. [[Sasha]] IMHO what you really say is "Let's treat BFD as one more L2 contro= l protocol".. The problem (as I see it) is that there is a clear definition= of what consitutes L2 control protocols (given by IEEE 802 and accepted by,= say, MEF when it discusses tunneling of these protocols). A multicast IP pa= cket would not be ever recognized as such. Clearly, this is an order of magnitude worse than what happens if w= e go with multicast IP encapsulation. [[Sasha]] Sorry, but I do not see any difference - for the reasons stated ab= ove. 1. * If LACP is used on LAG members and micro-BFD sessions do not use IP-= based encapsulation, they can be activated once LACP brings the link UP. [Manav] Yes. I think i had mentioned even earlier that BFD without IP based= encapsulation is perhaps the best. But that requires a well known MAC from= IEEE and a new Ether type. I am not sure how easy or complex this is. [[Sasha]] Neither do I, but it is worth trying IMHO. BTW, IETF already has a= block of MAC addresses allocated to it by IEEE 802 with IANA distributing a= ddresses within this block. So you probably need only a new Ethertype, and t= hese are usually reasonably easy to obtain. E.g., MEF has easily got one for= its CESoETH (MEF 8) protocol several years ago. * BFD sessions that do not use IP encapsulation can be used even if LACP= is not used on LAG members. In this case they will interact directly with t= he Aggregator rather than with LACP. 1. [Manav] I am not sure i understand why having an IP encapsulation precl= udes an implementation to directly interact with the Aggregator. In fact, al= l control packets from the micro BFD session will ONLY interact with the Agg= regator, and never with LACP. [[Sasha]] I suspect that this would create lots of conflicts because Aggrega= tor's understanding of the link status would be fed by two conflicting sourc= es: LACP session and micro-BFD session. 1. You've claimed that an IP-based encapsulation for micro-BFD that= uses unicast IP destination address and a dedicated UDP port (to differenti= ate it from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP= interfaces. I think that this is incorrect because RFC 5881 works for unnum= bered P2P IP interfaces as fine as for numbered ones. The relevant text is I= MHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it th= at is relevant to P2P links says that "the source address of a BFD Control p= acket MUST NOT be used to identify the session". [Manav] I am more concerned about the destination IP address than the source= IP. What dest IP to you use? Even if you do manage to use a 127/8, what des= t MAC do you use? Do you use a well known L2 MAC address for IP unicast base= d encaps. If Yes, then you need to get this from IEEE. [[Sasha]] What destination IP address do you use in RFC 5881? As for MAC, LA= G is assigned with its own MAC address (which may but does not have to match= MAC address of one of its member links), and, in the case of IP over LAG, i= s learned via ARP. Note that with multicast you dont need any L2 address allocation. 1. Last but not least, I do not think that my proposals require complicate= d coordination with IEEE 802.1AX. LAG-related state machines are well define= d, all you need is feeding existing some inputs into them from micro-BFD rat= her than from the physical layer, and activating micro-BFD sessions from the= m (which is a minor change IMO). However, to this extent coordination with I= EEE 802.1AX seems unavoidable unless you explicitly declare that LAG with m= icro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.= 1AX - and bear all the consequences of such a decision. [Manav] I am not worried about feeding state from the micro BFD sessions to= the LAG module - thats an implementation specific issue. What i am concerne= d about is getting their approval for a new ether type, L2 mac addr and new= encap that we want. [[Sasha]] I'd say you the only way to find out would be to try? Cheers, Manav This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69BILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Manav,
Lots of thanks for a prompt response.
 
Please see some comments inline  in green italics below (with snipped p= arts when we seem to be aligned).
 
Regards,
     Sasha
 
From: Bhatia, Mana= v (Manav) [manav.bhatia@alcatel-lucent.com]
Sent: Friday, December 16, 2011 10:29 AM
To: Alexander Vainshtein
Cc: rtg-bfd@ietf.org
Subject: RE: BFD on LAG interfaces

Hi Sasha,
 
Thanks for your comments.
 
My response's inline.=
 
... snipped...

 <= /span>You've said that the member link should come UP as soon as= the micro BFD session gets established and, based on t= his, you reject LACP (if used) as the mechanism for bringing the member= link UP - Will it not take LACP long (at least 1 secs) to bring the l= ink up? I see two issues with this logic:

    • Once the micro-BFD session goes DOWN, it= falls back to sending 1 BFD control packet per second (as explained in RFC= 5880, Section 6.8.3). Hence I would expect that bringing UP a failed member= link via the 5880-compliant micro-BFD session would take approximately as long as it would with LACP using a 1' t= imer. Or do you worry about LACP with 30' timers?  
  1. [Manav] If LACP uses= its default periodic timer of 30 secs, then that screws up BFD. T= his means that BFD on LAG will only work if the administrator manually changes the default LACP timer from 30s to 1sec. I am not ver= y comfortable with a solution that hinges on all administrators manually con= figuring something correctly for it to work - to me this is a very tenuous d= esign.

[[Sasha]] I see your point, but I do not think it is a very= serious issue. Misconfiguration can kill lots of protocols, and BFD is not= really an exception.

 
          [Manav]= This also necessitates running LACP along with BFD. I am ok if LACP can run= with BFD. I am not sure if i am ok with mandating LACP to run with BFD. But= then this is a personal choice ..
[[Sasha]] LACP is only required if you insist on= running BFD in an IP encapsulation.
    • If LACP is used on a LAG member that has= been brought DOWN by a micro-BFD session, it has to be involved i bringing the link UP anyway: it must declare the local link= state as "Collecting" and then go thru some stages until the link is recognized as "Collecting" and &quo= t;Distributing" by both peers. This would also take some time (probably= a few hundreds of milliseconds) because LACP is a slow protocol. Attempts t= o bypass the LACP procedures for bringing the link UP could easily run into serious interoperability problems - unless you are= ready to say that LAG with LACP and LAG with per-link BFD are mutually excl= usive. 
Which entity should activate the micro-B= FD session, and when? I've probably not expressed my position clearly enough= , hence your comment =  I think you meant that the micro BFD session would wait for the member link to come up before it gets restarted.&nb= sp;Why should it wait for the entire LAG to come up again? In fact in some c= ases the LAG will not even go DOWN when a micro BFD session goes down. What I've really meant is the following:
    • If micro-BFD sessions use IP-based en= capsulations, LAG (which is the interface that IP sees) MUST be UP befo= re they can be activated. As I've noted, if LAG is down it could safely drop= any IP packets it receives. You seem to have accepted this point.  =
     
    [Manav] LAG can only be UP, if there is atleast one compo= nent link that is alive. Yes what you have described is a deadlock. But= this is more so with Unicast encapsulation. With multicast, we could say that just as a port that is down processes certain&= nbsp;L2 control frames, it should also process frames coming with a well kno= wn IANA allocated multicast MAC (which would be used by all micro-BFD sessio= ns). If we were to go with a unicast IP encapsulation, then we will have to let the port that is down accept (i)= all broadcast frames (ARP requests) (ii) all packets coming with your own M= AC (ARP replies) (iii) all IP packets addressed to you.

[[Sasha]] IMHO what you r= eally say is "Let's treat BFD as one more L2 control protocol".. T= he problem (as I see it) is that there is a clear definition of what consitutes L2 control protocols (given by IEEE 802 and a= ccepted by, say, MEF when it discusses tunneling of these protocols). A mult= icast IP packet would not be ever recognized as such. 

     =     Clearly, this is an order= of magnitude worse than what happens if we go with multicast IP encapsulati= on.

[[Sasha]] Sorry,= but I do not see any difference - for the reasons stated above.

 

    • If LACP is used on LAG members and micro-= BFD sessions do not use IP-based encapsulation, they can be activated once L= ACP brings the link UP.  
     
    [Manav] Yes. I think i had mentioned even earlier that BFD wit= hout IP based encapsulation is perhaps the best. But that requires a well kn= own MAC from IEEE and a new Ether type. I am not sure how easy or complex this is.

[[Sasha]] Neithe= r do I, but it is worth trying IMHO. BTW, IETF already has a block of MAC addresses allocated to it by IEEE 802 with IANA= distributing addresses within this block. So you probably need only a new E= thertype, and these are usually reasonably easy to obtain. E.g., MEF has eas= ily got one for its CESoETH (MEF 8) protocol several years ago.

 

  • BFD sessions that do not use IP encapsula= tion can be used even if LACP is not used on LAG members. In this case they will interact directly with the Aggregator rather than= with LACP. 
  1. [Manav] I am not sure i understand why having an IP encapsulati= on precludes an implementation to directly interact with the Aggregator. In= fact, all control packets from the micro BFD session will ONLY interact with the Aggregator, and never with LACP.

 

[[Sasha]] I suspect that= this would create lots of conflicts because Aggregator's understanding of t= he link status would be fed by two conflicting sources: LACP session and micro-BFD session.

  1.       You've claimed that an IP-based encapsulation= for micro-BFD that uses unicast IP destination ad= dress and a dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6 s= ession) would will not work for unnumber= ed IP interfaces. I think that this is incorrect because RFC 5881 wor= ks for unnumbered P2P IP interfaces as fine as for numbered ones.= The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is= relevant to P2P links says that "the source address of a BFD Control packet MUST NOT= be used to identify the session". &n= bsp;
 
[Manav] I am more concerned about the destination IP= address than the source IP. What dest IP to you use? Even if you do ma= nage to use a 127/8, what dest MAC do you use? Do you use a well known L2 MAC address for IP unicast based encaps. If Yes, then y= ou need to get this from IEEE.
 
<= span class=3D"160165907-16122011">[[Sasha]] What destination IP address do you use in RFC 5881? As= for MAC, LAG is assigned with its own MAC address (which may but does not have to match MAC address of one of its mem= ber links), and, in the case of IP over LAG, is learned via ARP.=
 
Note that with multicast you dont need any L2 address allocati= on. 
  1. Last but not least, I do not think that m= y proposals require complicated coordination with IEEE 802.1AX. LAG-related= state machines are well defined, all you need is feeding existing some inpu= ts into them from micro-BFD rather than from the physical layer, and activating micro-BFD sessions from them (= which is a minor change IMO). However, to this extent coordination= with IEEE 802.1AX  seems unavoidable unless you explicitly declare tha= t LAG with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the consequences of= such a decision.  
 
[Manav] I am not worried about feeding state from the mic= ro BFD sessions to the LAG module - thats an implementation specific issue.= What i am concerned about is getting their approval for a new ether type, L2 mac addr and new encap that we want. = ;
 
[[Sasha]] I'd= say you the only way to find out would be to try?=
 
Cheers, Manav

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69BILPTMAIL02e_-- From manav.bhatia@alcatel-lucent.com Fri Dec 16 03:41:02 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 9817F21F8B1E for ; Fri, 16 Dec 2011 03:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZ6kgjaac7xy for ; Fri, 16 Dec 2011 03:41:02 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0495921F8B0D for ; Fri, 16 Dec 2011 03:41:01 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pBGBerfm024348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2011 05:40:57 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBGBerCd006812 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Dec 2011 17:10:53 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 16 Dec 2011 17:10:53 +0530 From: "Bhatia, Manav (Manav)" To: Alexander Vainshtein Date: Fri, 16 Dec 2011 17:10:53 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7wABf3ME0AA9Aj4AAGKKfiAADntQA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F1370@INBANSXCHMBSA1.in.alcatel-lucent.com> References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 11:41:02 -0000 Hi Sasha, =20 > [Manav] I am more concerned about the destination IP=20 > address than the source IP. What dest IP to you use? Even if you do=20 > manage to use a 127/8, what dest MAC do you use? Do you use a well=20 > known L2 MAC address for IP unicast based encaps. If Yes, then you need=20 > to get this from IEEE. > =20 > [[Sasha]] What destination IP address do you use in RFC 5881? As for > MAC, LAG is assigned with its own MAC address (which may but does=20 > not have to match MAC address of one of its member links), and, > in the case of IP over LAG, is learned via ARP. I don't think you do dynamic ARP over unnumbered interfaces. > [Manav] I am not worried about feeding state from the micro BFD sessions= =20 > to the LAG module - thats an implementation specific issue. What i am=20 > concerned about is getting their approval for a new ether type, L2 mac=20 > addr and new encap that we want. =20 > =20 > [[Sasha]] I'd say you the only way to find out would be to try? =20 Sure, that can be done. I will include some text on direct encapsulation ov= er L2 (without IP/UDP headers) in the next version. Right now we have three encapsulation options for the micro-BFD sessions. 1. Using multicast dest IP 2. Using Unicast IP 3. Direct encapsulation of the BFD packet without IP/UDP headers I think its clear that there is value in implementing (3) as long as we can= get IEEE to part with some of its treasure. What about (1) and (2)? I will= raise a separate thread to discuss the preferred IP encapsulation scheme. Regarding (1), I am sure someone on the list can illuminate us on what it e= ntails to get a well known MAC and an Ether Type from IEEE for our purpose.= This was done for TRILL recently and I can ping the TRILL folks on this, u= nless someone on this list already has this information, and is kind enough= to share it with us. Cheers, Manav From gregory.mirsky@ericsson.com Fri Dec 16 08:45:52 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 29C3421F8BB3 for ; Fri, 16 Dec 2011 08:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxdlSh2VtIWF for ; Fri, 16 Dec 2011 08:45:50 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7944521F8B77 for ; Fri, 16 Dec 2011 08:45:50 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBGGinUR008593; Fri, 16 Dec 2011 10:45:46 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 16 Dec 2011 11:45:12 -0500 From: Gregory Mirsky To: Alexander Vainshtein , "Bhatia, Manav (Manav)" Date: Fri, 16 Dec 2011 11:45:11 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7wABf3ME0AA9Aj4AAGKKfiAAw0QxA= Message-ID: References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF132297C9814EUSAACMS0715e_" 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: Fri, 16 Dec 2011 16:45:52 -0000 --_000_FE60A4E52763E84B935532D7D9294FF132297C9814EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sasha, Manav, et al., I agree with Sasha that non-IP encapsulation of BFD over Ethernet is attain= able and will refer to draft-fbb-mpls-tp-ethernet-addressing-00 that reques= ts allocation multicast MAC by IANA: "IANA is requested to allocate an Ethernet Multicast Address from the Ether= net Multicast Addresses table in the ethernet-numbers registry for use by M= PLS-TP LSRs over point-to-point links as described in Section 2." Regards, Greg ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: Friday, December 16, 2011 3:13 AM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Manav, Lots of thanks for a prompt response. Please see some comments inline in green italics below (with snipped parts= when we seem to be aligned). Regards, Sasha ________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Friday, December 16, 2011 10:29 AM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Hi Sasha, Thanks for your comments. My response's inline. ... snipped... You've said that the member link should come UP as soon as the micro BFD s= ession gets established and, based on this, you reject LACP (if used) as th= e mechanism for bringing the member link UP - Will it not take LACP long (a= t least 1 secs) to bring the link up? I see two issues with this logic: * Once the micro-BFD session goes DOWN, it falls back to sending 1 BF= D control packet per second (as explained in RFC 5880, Section 6.8.3). Henc= e I would expect that bringing UP a failed member link via the 5880-complia= nt micro-BFD session would take approximately as long as it would with LACP= using a 1' timer. Or do you worry about LACP with 30' timers? * 1. [Manav] If LACP uses its default periodic timer of 30 secs, then that = screws up BFD. This means that BFD on LAG will only work if the administrat= or manually changes the default LACP timer from 30s to 1sec. I am not very = comfortable with a solution that hinges on all administrators manually conf= iguring something correctly for it to work - to me this is a very tenuous d= esign. [[Sasha]] I see your point, but I do not think it is a very serious issue. = Misconfiguration can kill lots of protocols, and BFD is not really an excep= tion. [Manav] This also necessitates running LACP along with BFD. I am = ok if LACP can run with BFD. I am not sure if i am ok with mandating LACP t= o run with BFD. But then this is a personal choice .. [[Sasha]] LACP is only required if you insist on running BFD in an IP encap= sulation. 1. * If LACP is used on a LAG member that has been brought DOWN by a mic= ro-BFD session, it has to be involved i bringing the link UP anyway: it mus= t declare the local link state as "Collecting" and then go thru some stages= until the link is recognized as "Collecting" and "Distributing" by both pe= ers. This would also take some time (probably a few hundreds of millisecond= s) because LACP is a slow protocol. Attempts to bypass the LACP procedures = for bringing the link UP could easily run into serious interoperability pro= blems - unless you are ready to say that LAG with LACP and LAG with per-lin= k BFD are mutually exclusive. * Which entity should activate the micro-BFD session, and when? I've probably= not expressed my position clearly enough, hence your comment I think you = meant that the micro BFD session would wait for the member link to come up = before it gets restarted. Why should it wait for the entire LAG to come up = again? In fact in some cases the LAG will not even go DOWN when a micro BFD= session goes down. What I've really meant is the following: 1. * If micro-BFD sessions use IP-based encapsulations, LAG (which is th= e interface that IP sees) MUST be UP before they can be activated. As I've = noted, if LAG is down it could safely drop any IP packets it receives. You = seem to have accepted this point. [Manav] LAG can only be UP, if there is atleast one component link that is = alive. Yes what you have described is a deadlock. But this is more so with = Unicast encapsulation. With multicast, we could say that just as a port tha= t is down processes certain L2 control frames, it should also process frame= s coming with a well known IANA allocated multicast MAC (which would be use= d by all micro-BFD sessions). If we were to go with a unicast IP encapsulat= ion, then we will have to let the port that is down accept (i) all broadcas= t frames (ARP requests) (ii) all packets coming with your own MAC (ARP repl= ies) (iii) all IP packets addressed to you. [[Sasha]] IMHO what you really say is "Let's treat BFD as one more L2 contr= ol protocol".. The problem (as I see it) is that there is a clear definitio= n of what consitutes L2 control protocols (given by IEEE 802 and accepted b= y, say, MEF when it discusses tunneling of these protocols). A multicast IP= packet would not be ever recognized as such. Clearly, this is an order of magnitude worse than what happens if = we go with multicast IP encapsulation. [[Sasha]] Sorry, but I do not see any difference - for the reasons stated a= bove. 1. * If LACP is used on LAG members and micro-BFD sessions do not use IP= -based encapsulation, they can be activated once LACP brings the link UP. [Manav] Yes. I think i had mentioned even earlier that BFD without IP based= encapsulation is perhaps the best. But that requires a well known MAC from= IEEE and a new Ether type. I am not sure how easy or complex this is. [[Sasha]] Neither do I, but it is worth trying IMHO. BTW, IETF already has = a block of MAC addresses allocated to it by IEEE 802 with IANA distributing= addresses within this block. So you probably need only a new Ethertype, an= d these are usually reasonably easy to obtain. E.g., MEF has easily got one= for its CESoETH (MEF 8) protocol several years ago. * BFD sessions that do not use IP encapsulation can be used even if LACP= is not used on LAG members. In this case they will interact directly with = the Aggregator rather than with LACP. 1. [Manav] I am not sure i understand why having an IP encapsulation prec= ludes an implementation to directly interact with the Aggregator. In fact, = all control packets from the micro BFD session will ONLY interact with the = Aggregator, and never with LACP. [[Sasha]] I suspect that this would create lots of conflicts because Aggreg= ator's understanding of the link status would be fed by two conflicting sou= rces: LACP session and micro-BFD session. 1. You've claimed that an IP-based encapsulation for micro-BFD that= uses unicast IP destination address and a dedicated UDP port (to different= iate it from a 1-hop IPv4/IPv6 session) would will not work for unnumbered = IP interfaces. I think that this is incorrect because RFC 5881 works for un= numbered P2P IP interfaces as fine as for numbered ones. The relevant text = is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of = it that is relevant to P2P links says that "the source address of a BFD Con= trol packet MUST NOT be used to identify the session". [Manav] I am more concerned about the destination IP address than the sourc= e IP. What dest IP to you use? Even if you do manage to use a 127/8, what d= est MAC do you use? Do you use a well known L2 MAC address for IP unicast b= ased encaps. If Yes, then you need to get this from IEEE. [[Sasha]] What destination IP address do you use in RFC 5881? As for MAC, L= AG is assigned with its own MAC address (which may but does not have to mat= ch MAC address of one of its member links), and, in the case of IP over LAG= , is learned via ARP. Note that with multicast you dont need any L2 address allocation. 1. Last but not least, I do not think that my proposals require complicat= ed coordination with IEEE 802.1AX. LAG-related state machines are well defi= ned, all you need is feeding existing some inputs into them from micro-BFD = rather than from the physical layer, and activating micro-BFD sessions from= them (which is a minor change IMO). However, to this extent coordination w= ith IEEE 802.1AX seems unavoidable unless you explicitly declare that LAG = with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023= ad/802.1AX - and bear all the consequences of such a decision. [Manav] I am not worried about feeding state from the micro BFD sessions to= the LAG module - thats an implementation specific issue. What i am concern= ed about is getting their approval for a new ether type, L2 mac addr and ne= w encap that we want. [[Sasha]] I'd say you the only way to find out would be to try? Cheers, Manav This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_FE60A4E52763E84B935532D7D9294FF132297C9814EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Sasha, Manav, et al.,
I agree with Sash= a that=20 non-IP encapsulation of BFD over Ethernet is attainable and will refer to=20 draft-fbb-mpls-tp-ethernet-addressing-00 that requests allocation multicast= MAC=20 by IANA:
"IANA is requested to allocate an Ethernet Multicast Address fr= om=20 the Ethernet Multicast Addresses table in the ethernet-numbers registry for= use=20 by MPLS-TP LSRs over point-to-point links as described in Section 2."

Regards,
Greg

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: Friday, December 16, 2011 3:13 AM
To:= =20 Bhatia, Manav (Manav)
Cc: rtg-bfd@ietf.org
Subject: RE:= BFD=20 on LAG interfaces

Manav,
Lots of thanks for a prompt=20 response.
 
Please see some comments inline  in green italics below (with snipped parts= when=20 we seem to be aligned).
 
Regards,
     Sasha
 
From: Bhatia, Manav (Ma= nav)=20 [manav.bhatia@alcatel-lucent.com]
Sent: Friday, December 16, 2011= =20 10:29 AM
To: Alexander Vainshtein
Cc:=20 rtg-bfd@ietf.org
Subject: RE: BFD on LAG=20 interfaces

Hi Sasha,
 
Thanks for your comments.
 
My response's inline.
 
= ...=20 snipped...

 You've said that the member=20 link should come UP as soon as t= he micro=20 BFD session gets established and, based on this,=20 you reject LACP (if used) as the mechanism for bringing the member l= ink=20 UP - Will it not take LA= CP long (at=20 least 1 secs) to bring the link up? I see two= =20 issues with this logic:

    • Once the micro-BFD session goes DO= WN, it=20 falls back to sending 1 BFD control packet per second (as explained i= n RFC=20 5880, Section 6.8.3). Hence I would expect that bringing UP a failed= =20 member link via the 5880-compliant micro-BFD session would take=20 approximately as long as it would with LACP using a 1' timer. Or= =20 do you worry about LACP with 30' timers?  =20
  1. = [Manav] If=20 LACP uses its default periodic timer of 30 secs, then that screws = up=20 BFD. This means that BFD on LAG will only work if the=20 administrator manually changes the default LACP timer from 30s to = 1sec.=20 I am not very comfortable with a solution that hinges on all administra= tors=20 manually configuring something correctly for it to work - to me this is= a=20 very tenuous design.

[[Sasha]] I see your point, but I do not think it is a ver= y=20 serious issue. Misconfiguration can kill lots of protocols, and BFD is = not=20 really an exception.

 
          [Manav] T= his=20 also necessitates running LACP along with BFD. I am ok if LACP can run wi= th=20 BFD. I am not sure if i am ok with mandating LACP to run with BFD. But th= en=20 this is a personal choice ..
[[Sasha]] LACP is only required if you insist on running B= FD in=20 an IP encapsulation.
    • If LACP is used on a LAG member th= at has=20 been brought DOWN by a micro-BFD session, it has to be=20 involved i bringing the link UP anyway: it = must=20 declare the local link state as "Collecting" and then go thru some st= ages=20 until the link is recognized as "Collecting" and "Distributing" by bo= th=20 peers. This would also take some time (probably a few hundreds of=20 milliseconds) because LACP is a slow protocol. Attempts to bypass the= LACP=20 procedures for bringing the link UP could easily run into serious=20 interoperability problems - unless you are ready to say that LAG with= LACP=20 and LAG with per-link BFD are mutually exclusive. =20
Which entity should activate the micr= o-BFD=20 session, and when? I've probably not expressed my position clearly enough= ,=20 hence your comment  I think you meant that the micro BFD session wou= ld wait=20 for the member link to come up before it gets restarted. Why sh= ould=20 it wait for the entire LAG to come up again? In fact in some cases the LA= G=20 will not even go DOWN when a micro BFD session goes down. What I'v= e=20 really meant is the following:
    • If micro-BFD sessions use IP-b= ased=20 encapsulations, LAG (which is the interface that IP sees) MUST b= e UP=20 before they can be activated. As I've noted, if LAG is down it could= =20 safely drop any IP packets it receives. You seem to have accepted thi= s=20 point.  
     
    [Manav] LAG can only be UP, if there is atleast one compo= nent=20 link that is alive. Yes what you have described is a deadlock. But= this=20 is more so with Unicast encapsulation. With multicast, we could say tha= t=20 just as a port that is down processes certain L2 control frames, i= t=20 should also process frames coming with a well known IANA allocated mult= icast=20 MAC (which would be used by all micro-BFD sessions). If we were to go w= ith a=20 unicast IP encapsulation, then we will have to let the port that is dow= n=20 accept (i) all broadcast frames (ARP requests) (ii) all packets coming = with=20 your own MAC (ARP replies) (iii) all IP packets addressed to=20 you.

[[Sasha]] IMHO what you reall= y say is=20 "Let's treat BFD as one more L2 control protocol".. The problem (as I s= ee=20 it) is that there is a clear definition of what consitutes L2 control=20 protocols (given by IEEE 802 and accepted by, say, MEF when it discusse= s=20 tunneling of these protocols). A multicast IP packet would not be ever= =20 recognized as such. 

       &n= bsp;=20 Clearly, this is an order o= f magnitude=20 worse than what happens if we go with multicast IP=20 encapsulation.

[[Sasha]] Sorry, but I do not= see any=20 difference - for the reasons stated=20 above.

 

    • If LACP is used on LAG members and= =20 micro-BFD sessions do not use IP-based encapsulation, they can be=20 activated once LACP brings the link UP.  
     
    [Manav] Yes. I think i had mentioned even ea= rlier=20 that BFD without IP based encapsulation is perhaps the best. But that=20 requires a well known MAC from IEEE and a new Ether type. I am not sure= how=20 easy or complex this is.

= [[Sasha]]=20 Neither do I, but it is worth trying IMHO. BTW, IETF already has a bloc= k of=20 MAC addresses allocated to it by IEEE 802 with IANA distributing addres= ses=20 within this block. So you probably need only a new Ethertype, and these= are=20 usually reasonably easy to obtain. E.g., MEF has easily got one for its= =20 CESoETH (MEF 8) protocol several years=20 ago.

 

  • BFD sessions that do not use IP=20 encapsulation can be used even if LACP is not used on LAG members. = In=20 this case they will interact directly with the Aggregator rather than w= ith=20 LACP. 
  1. [Manav] I am not sure i understand why havin= g an IP=20 encapsulation precludes an implementation to directly interact with the= =20 Aggregator. In fact, all control packets from the micro BFD session wil= l=20 ONLY interact with the Aggregator, and never with LACP.=20

 

[[Sasha]] I suspect that this= would=20 create lots of conflicts because Aggregator's understanding of the link= =20 status would be fed by two conflicting sources: LACP session and micro-= BFD=20 session.

  1.      = You've claimed that an IP-based encapsulation = for=20 micro-BFD that uses unicast IP destination ad= dress=20 and a dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6=20 session) would will not wor= k for=20 unnumbered IP interfaces. I think that this is incorrect because= RFC=20 5881 works for unnumbered P2P IP interfaces as fine as for=20 numbered ones. The relevant text is IMHO in Section 6=20 "Addressing issues" of RFC 5881, and the only part of it that is releva= nt to=20 P2P links says that "the source address of a BFD Control packet MUST NOT be= used=20 to identify the session".  
 
[Manav] I am more concerned about the destination IP a= ddress=20 than the source IP. What dest IP to you use? Even if you do manage t= o use=20 a 127/8, what dest MAC do you use? Do you use a well known L2 MAC address= for=20 IP unicast based encaps. If Yes, then you need to get this from=20 IEEE.
 
[[Sasha]]=20 What destination IP address do you use in RFC 5881? As for MAC, LAG is=20 assigned with its own MAC address (which may but does not have to match M= AC=20 address of one of its member links), and, in the case of IP over LAG, is= =20 learned via ARP.
 
Note=20 that with multicast you dont need any L2 address=20 allocation. 
  1. Last but not least, I do not think t= hat my=20 proposals require complicated coordination with IEEE 802.1AX. LAG-relat= ed=20 state machines are well defined, all you need is feeding existing some= =20 inputs into them from micro-BFD rather than from the physic= al=20 layer, and activating micro-BFD sessions from them (which is = a=20 minor change IMO). However, to this extent coordination with IEEE= =20 802.1AX  seems unavoidable unless you explicitly declare that LAG = with=20 micro-BFD sessions is mutually exclusive with one defined by IEEE=20 8023ad/802.1AX - and bear all the consequences of such a=20 decision.  
 
[Manav] I am not worried about feeding st= ate=20 from the micro BFD sessions to the LAG module - thats an implementation=20 specific issue. What i am concerned about is getting their approval for a= new=20 ether type, L2 mac addr and new encap that we want.  <= /DIV>
 
[[Sasha]]=20 I'd say you the only way to find out would be to=20 try?
 
Cheers,=20 Manav

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_FE60A4E52763E84B935532D7D9294FF132297C9814EUSAACMS0715e_-- From marc@sniff.de Fri Dec 16 08:59:10 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 9E42A21F8B3D for ; Fri, 16 Dec 2011 08:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMkuufFDaxv3 for ; Fri, 16 Dec 2011 08:59:09 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CBD21F8B3B for ; Fri, 16 Dec 2011 08:59:08 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CF3F12AA0F; Fri, 16 Dec 2011 16:59:06 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Marc Binderberger In-Reply-To: Date: Fri, 16 Dec 2011 17:59:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Alexander Vainshtein X-Mailer: Apple Mail (2.1084) Cc: Dave Katz , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 16:59:10 -0000 Hello Alexander, tried to reply to the end of this thread but it was too difficult to = follow the many replies. > Here is my understanding of the problem we try to solve: > 1. We are dealing with a LAG between a pair of, say adjacent routers = that is:: > a. Comprised of links that do not support detection of failure at the = physical layer (e.g., loss of optical power) =96 if they were, we would = not need BFD to do the same. (There are several scenarios when detection = of link failure at the physical layer is problematic in the real-world = deployments) correct. > b. Expected to go down while some of the comprising links are still up = (otherwise the regular 1-hop BFD session would probably do the job). yes > 2. We want to detect the =93insufficient number of active links=94 = condition much faster than could be done by using standard LACP, and to = bring the LAG down based on this condition. yes but ... the draft is clearly written with "bring the LAG down" in = mind. But one could alternatively let the LAG aside and use BFD to = initiate a reroute of traffic away from the LAG interface. My impression = is that Greg and Jeff implemented along this line. > 3. The situation when LAG goes down due to insufficient number of = active links must be reversible, i.e., the LAG must be able to go UP = once this condition disappears. yes, I would prefer this ;-) > Do these notes capture the problem space correctly? Or did I miss = something important? >=20 > One point that is not clear to me is the timeframe for bringing = constituent links of a LAG up. I would expect that the requirements for = that could be much more relaxed (e.g., in order to avoid link flapping). = Is that correct? If it is, one possible implication is that it is = possible to use different mechanisms for bringing links DOWN and UP. To = the best of my understanding, this is how BFD is supposed to be used = with routing adjacencies today, i.e. BFD can bring the adjacency DOWN = quite fast, but it has to be brought UP by the appropriate routing = protocol. the draft allows this, section 3.2 "To avoid this deadlock ...". So = using BFD to bring down fast alone is covered. Now RFC5882, e.g. section = 4.1, mentions that waiting for BFD's Up notification may be useful. Thus = we allowed this in the draft as well. [I skip the LACP, CFM part. We had this. Nothing wrong technically but = somehow customers push BFD teams to deliver] > 3. BFD in some special encapsulation: > a. Any such encapsulation must provide for distinguishing between a = BFD session that is supposed to run over the LAG as a whole and a BFD = session that is supposed to run over a specific constituent link of the = LAG. Ability to distinguish between these should exist even before the = session has been fully established (i.e., when the Active side sends out = a packet with Your Discriminator set to 0). This looks to me as an = absolute requirement Not sure about "absolute" but I agree that running the per-member (aka = micro) sessions should be possible in parallel to BFD over the whole = LAG. > b. The nascent BFD session that has been identified as link-specific = would be bound to the constituent physical link from which its first = packet has been received > c. BFD packets that have been received with a valid Your = Discrimination that has been associated with a specific physical link = but came from a different physical link MUST be discarded (similar to = what happens with received BFD packets that fail the authentication = checks) right, interesting detail. I think we should add this to the section 3. > d. Failure of a BFD session that has been bound to a specific = constituent link of a LAG would be interpreted as the link going DOWN, = and an appropriate indication passed to the Aggregator(see IEEE = 802.3-2005, Clause 43) so that it can: reminds me, if we stick to the close interaction with the LAG then we = likely need a paragraph explaining "LMM" and linking it to the term = aggregator. > i. Disable collection and distribution on that link > ii. Declare LAG DOWNM if the number of active links has decreased = below the minimal number of links, and pass this indication to various = MAC clients > 4. If LACP is used with the LAG in question, bringing the links UP = (and, if necessary, bringing LAG as a whole UP) can be relegated to it. = There is no need to overload BFD (or any other solution =96 excluding, = of course, faster LACP) with this functionality. see my comment above. Agree, we don't need BFD to bring up. But it's not = overloading, coupling the protocol "bringup" with BFD's Up state exist = in other cases as well (e.g. ISIS) > This means that IP-based BFD encapsulations can be safely used as = solutions in this case. I'm not sure. I don't think that Dave Katz' reply was about bringing up = the LAG session - the draft allows to ignore BFD for bringing up anyway. = It's about the APIs you use. > a. The BFD session using an IP-based encapsulation that has been bound = to a link in a LAG that went DOWN would wait for LAG coming UP again in = order to be restarted. > b. This scheme seems to eliminate the potential deadlock mentioned by = Manav in his response to Nitin. indeed. > i. IMHO and FWIW the approach described by Nitin (a dedicated UDP = port) is preferable It's a way to differentiate micro from LAG ("macro"?) session. = Personally I prefer the destination IP to differentiate (similar to = RFC5884, only I wouldn't use 127/8 exactly because it's in use already = by this RFC). Guess this one can be debated ad infinitum :-) > ii. In any way i suspect that usage of IP encapsulations with = multicast IP addresses would not help: If LAG, as an IP interface, goes = down, it may safely discard any IP packets it receives ??? the multicast IP was for: (a) having a mcast MAC and (b) having a = dedicated IP address. Not sure how this fits into (i) talking about UDP ports. [skipping the LAG w/o LACP. Have to think about it :-) ] Regards, Marc >=20 > Again, did I miss something? >=20 > Regards, > Sasha >=20 > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Greg Mirsky > Sent: Thursday, December 15, 2011 7:53 AM > To: Dave Katz > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAG interfaces >=20 > Dear Dave and All, > I think that Mach brought the right point and that problem we can work = is not just BFD over LAG's constituent link but, as Dave pointed = earlier, BFD over Ethernet, with or without IP addressing. And I'll draw = parallel with RFC 5885 and RFC 6428 that use BFD over MPLS, i.e. ACH = VCCV encapsulation without IP header. >=20 > Regards, > Greg > On Wed, Dec 14, 2011 at 7:01 PM, Dave Katz wrote: >=20 > On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote: >>=20 >>> As far as this particular draft goes, I think trying to make >>> this work over IP creates a whole pile of issues that cannot >>> be solved in a standard way, because it essentially requires >>> that BFD tap into private APIs in order to work. >>=20 >> I am not sure I understand what private APIs are you referring to. I = think the confusion stems from the two modes that we have defined in Sec = 4. > My point is that running IP over an individual leg is an unnatural = act, as it is architecturally incompatible with how LAGs are supposed to = work (IMHO). As a result, implementers have to hack something into = their implementations to sort-of-pretend-but-not-really that IP is = enabled on the individual legs. >=20 > There is no good way to spec such a thing because there isn't supposed = to be any IP binding to the individual leg. What you're doing, in = effect, is modifying the definition of a LAG in order to shoehorn BFD = into the picture, which is rather out-of-scope for the BFD group (and = for the IETF in general). I don't see how it would be possible to = standardize such a thing. >=20 >>=20 >> In the first mode we just run BFD over the member links. There is no = additional BFD running over the whole bundle. In this mode, BFD is = simply replacing LACP. It keeps track of all the links that are alive = and informs the LAG manager (or some entity, beyond the scope of this = document) about it. The IP interface over the LAG is torn down once the = number of remaining links reaches the minimum threshold number. BFD is = thus used to decide the fate of an IP interface. >>=20 >> We had kept this mode as the default mode. >>=20 >> I am now having second thoughts on whether this is the right thing to = do or not. > It's a reasonable thing if all you're doing is replacing LACP with BFD = as the per-leg liveness test; it makes BFD invisible to applications, = as the service interface is the top of the LAG. This is subtly = different than having a BFD-over-the-top session in addition to the = individual legs, as doing so provides visible BFD semantics rather than = LAG semantics, and the service interface reflects those semantics (so = you can potentially do things like AdminDown and the like). >>=20 >> Then there is the second mode described in Section 4. >>=20 >> Establish BFD sessions over each member link. The aggregate result of = this decides the fate of only the LAG (and not that of the IP interface = defined above it). Establish another BFD session over the LAG (which is = what most implementations do today) that runs sedate timers and ensures = IP reachability with the other end. This mode gives us the best of both = worlds. >>=20 >> Would it make more sense to keep this mode as default and completely = do away with the first mode that we have defined? > I'm agnostic about the choices; I can see some benefit in both. But = the real problem is how to do the per-link stuff in a reasonable way. >=20 > --Dave >=20 >=20 >=20 > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >=20 -- Marc Binderberger From marc@sniff.de Fri Dec 16 09:20:10 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 5ECBB21F8B72 for ; Fri, 16 Dec 2011 09:20:10 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2E310GJmyjJ for ; Fri, 16 Dec 2011 09:20:09 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8D521F87D3 for ; Fri, 16 Dec 2011 09:20:09 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id B43D82AA0F; Fri, 16 Dec 2011 17:20:07 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Fri, 16 Dec 2011 18:20:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C362EEF9C7896468B36C9B79200D8350D026F0D2C@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F0FFF@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F101B@INBANSXCHMBSA1.in.alcatel-lucent.com> <98968DB0-A185-434C-ADFF-7AC0F61C6370@juniper.net> <7C362EEF9C7896468B36C9B79200D8350D026F103C@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Dave Katz 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: Fri, 16 Dec 2011 17:20:10 -0000 Hello Dave, trying to understand the "private API" statement. >>> As far as this particular draft goes, I think trying to make=20 >>> this work over IP creates a whole pile of issues that cannot=20 >>> be solved in a standard way, because it essentially requires=20 >>> that BFD tap into private APIs in order to work. >>=20 >> [...]=20 >=20 > My point is that running IP over an individual leg is an unnatural = act, as it is architecturally incompatible with how LAGs are supposed to = work (IMHO). As a result, implementors have to hack something into = their implementations to sort-of-pretend-but-not-really that IP is = enabled on the individual legs. If you receive an IP packet on a member link then is it this problem you = face (?): (i) an IP/UDP socket can be opened for the whole LAG, as it has an IP = address. Likely the socket would exist per-system and extensions would = allow to either bind it to the LAG or to receive the interface = information together with the packet (ii) opening an IP/UDP socket for a member link interface can not be = expected to work as the member link may not be "IP activated". (iii) opening an "Ethernet socket" for a particular Ethertype and = interface should work (assuming your OS offers this kind of socket) Unless in (i) the implementation provides you with the information of = the member link the packet was received on or allows you in (ii) to = bind the IP/UDP socket to the member link , unless one of this is given = one could not use IP/UDP encapsulation for the micro sessions. Does this describe the problem? Now for BFD in RFC5880/5881 we also need the interface information to = handle your_discr zero packets. Why was it okay to assume you know this = information from the API but we cannot assume that the member-interface = information is provided in (i) above? Or in other words: what API model can we assume when defining a = standard? Thanks & Regards, Marc On 2011-12-15, at 4:01 , Dave Katz wrote: >=20 > On Dec 14, 2011, at 4:58 PM, Bhatia, Manav (Manav) wrote: >>=20 >>> As far as this particular draft goes, I think trying to make=20 >>> this work over IP creates a whole pile of issues that cannot=20 >>> be solved in a standard way, because it essentially requires=20 >>> that BFD tap into private APIs in order to work. >>=20 >> I am not sure I understand what private APIs are you referring to. I = think the confusion stems from the two modes that we have defined in Sec = 4.=20 >=20 > My point is that running IP over an individual leg is an unnatural = act, as it is architecturally incompatible with how LAGs are supposed to = work (IMHO). As a result, implementors have to hack something into = their implementations to sort-of-pretend-but-not-really that IP is = enabled on the individual legs. >=20 > There is no good way to spec such a thing because there isn't supposed = to be any IP binding to the individual leg. What you're doing, in = effect, is modifying the definition of a LAG in order to shoehorn BFD = into the picture, which is rather out-of-scope for the BFD group (and = for the IETF in general). I don't see how it would be possible to = standardize such a thing. >=20 >>=20 >> In the first mode we just run BFD over the member links. There is no = additional BFD running over the whole bundle. In this mode, BFD is = simply replacing LACP. It keeps track of all the links that are alive = and informs the LAG manager (or some entity, beyond the scope of this = document) about it. The IP interface over the LAG is torn down once the = number of remaining links reaches the minimum threshold number. BFD is = thus used to decide the fate of an IP interface.=20 >>=20 >> We had kept this mode as the default mode. >>=20 >> I am now having second thoughts on whether this is the right thing to = do or not. >=20 > It's a reasonable thing if all you're doing is replacing LACP with BFD = as the per-leg liveness test; it makes BFD invisible to applications, = as the service interface is the top of the LAG. This is subtly = different than having a BFD-over-the-top session in addition to the = individual legs, as doing so provides visible BFD semantics rather than = LAG semantics, and the service interface reflects those semantics (so = you can potentially do things like AdminDown and the like). >>=20 >> Then there is the second mode described in Section 4. >>=20 >> Establish BFD sessions over each member link. The aggregate result of = this decides the fate of only the LAG (and not that of the IP interface = defined above it). Establish another BFD session over the LAG (which is = what most implementations do today) that runs sedate timers and ensures = IP reachability with the other end. This mode gives us the best of both = worlds. >>=20 >> Would it make more sense to keep this mode as default and completely = do away with the first mode that we have defined? >=20 > I'm agnostic about the choices; I can see some benefit in both. But = the real problem is how to do the per-link stuff in a reasonable way. >=20 > --Dave >=20 -- Marc Binderberger From marc@sniff.de Sat Dec 17 02:28:11 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 A528821F8BE9 for ; Sat, 17 Dec 2011 02:28:11 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq2DZqsNa3cG for ; Sat, 17 Dec 2011 02:28:10 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F61921F8BDC for ; Sat, 17 Dec 2011 02:28:09 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CEE302AA0F; Sat, 17 Dec 2011 10:28:04 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-65614646 From: Marc Binderberger In-Reply-To: Date: Sat, 17 Dec 2011 11:28:01 +0100 Message-Id: <4E356AD7-0E1E-448E-B6E9-8D357F1AA30F@sniff.de> References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Alexander Vainshtein , "Bhatia, Manav (Manav)" , Mach Chen X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 10:28:11 -0000 --Apple-Mail-2-65614646 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Alexander, now I found the time to read this as well ... few questions to you: - it seems that defining the "bringing down" of a LAG member link via = BFD micro session is mainly a matter of referring to the particular = state(-changes) in aggregation control of 802.1AX ? So no changes = required within 802.1AX definition itself, in your opinion? - the "bringing up" though does require changes in 802.1AX, if we want = to make it dependent on BFD? I wonder already about basics like "do I = bring up LACP first and then BFD? Or vice versa? Or both in parallel?".=20= Btw, the customers I know largely do use both, LACP and the BFD on LAG = member links. LACP does the right job to organize a bundle in general - = it's just a bit slow. Which also means when LACP is configured one = probably wants both protocols signalling their "go" before a link it = brought into forwarding (_if_ you want to make it depending on BFD, I = mean). Alexander, you mentioned: The problem (as I see it) is that there is a clear definition of what = consitutes L2 control protocols (given by IEEE 802 and accepted by, say, = MEF when it discusses tunneling of these protocols). A multicast IP = packet would not be ever recognized as such.=20 - do you have a pointer to the definition? - you see this as a problem for the case when BFD is used to "bring up", = correct? Once the LAG is up then using e.g. IPv4 or IPv6 related = multicast MAC is fine in your opinion? About approvals from 802.1AX and a draft that requires such approvals my = opinion is it's the wrong direction. Faster LACP implementation(s) exist = - proprietary, I assume - and if this hasn't been managed to be = standardized yet then I don't see why BFD should have any better chance. As much as I like the insight I gained from this discussion between = Alexander and Manav, I wonder how much of this can be standardized in an = IETF draft. Maybe we should define the core mechanics of BFD on Lag = member links (BLM for short) and make the result of this 802.1AX centric = discussion a section of how BLM could be used with LAG, marked as = informal? Regards, Marc On 2011-12-16, at 12:12 , Alexander Vainshtein wrote: > Manav, > Lots of thanks for a prompt response. > =20 > Please see some comments inline in green italics below (with snipped = parts when we seem to be aligned). > =20 > Regards, > Sasha > =20 > From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Friday, December 16, 2011 10:29 AM > To: Alexander Vainshtein > Cc: rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces >=20 > Hi Sasha, > =20 > Thanks for your comments. > =20 > My response's inline. > =20 > ... snipped... > You've said that the member link should come UP as soon as the micro = BFD session gets established and, based on this, you reject LACP (if = used) as the mechanism for bringing the member link UP - Will it not = take LACP long (at least 1 secs) to bring the link up? I see two issues = with this logic: >=20 > Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD = control packet per second (as explained in RFC 5880, Section 6.8.3). = Hence I would expect that bringing UP a failed member link via the = 5880-compliant micro-BFD session would take approximately as long as it = would with LACP using a 1' timer. Or do you worry about LACP with 30' = timers? =20 > [Manav] If LACP uses its default periodic timer of 30 secs, then that = screws up BFD. This means that BFD on LAG will only work if the = administrator manually changes the default LACP timer from 30s to 1sec. = I am not very comfortable with a solution that hinges on all = administrators manually configuring something correctly for it to work - = to me this is a very tenuous design. > [[Sasha]] I see your point, but I do not think it is a very serious = issue. Misconfiguration can kill lots of protocols, and BFD is not = really an exception. >=20 > =20 > [Manav] This also necessitates running LACP along with BFD. = I am ok if LACP can run with BFD. I am not sure if i am ok with = mandating LACP to run with BFD. But then this is a personal choice .. > [[Sasha]] LACP is only required if you insist on running BFD in an IP = encapsulation. > If LACP is used on a LAG member that has been brought DOWN by a = micro-BFD session, it has to be involved i bringing the link UP anyway: = it must declare the local link state as "Collecting" and then go thru = some stages until the link is recognized as "Collecting" and = "Distributing" by both peers. This would also take some time (probably a = few hundreds of milliseconds) because LACP is a slow protocol. Attempts = to bypass the LACP procedures for bringing the link UP could easily run = into serious interoperability problems - unless you are ready to say = that LAG with LACP and LAG with per-link BFD are mutually exclusive.=20 > Which entity should activate the micro-BFD session, and when? I've = probably not expressed my position clearly enough, hence your comment I = think you meant that the micro BFD session would wait for the member = link to come up before it gets restarted. Why should it wait for the = entire LAG to come up again? In fact in some cases the LAG will not even = go DOWN when a micro BFD session goes down. What I've really meant is = the following: > If micro-BFD sessions use IP-based encapsulations, LAG (which is the = interface that IP sees) MUST be UP before they can be activated. As I've = noted, if LAG is down it could safely drop any IP packets it receives. = You seem to have accepted this point. =20 > =20 > [Manav] LAG can only be UP, if there is atleast one component link = that is alive. Yes what you have described is a deadlock. But this is = more so with Unicast encapsulation. With multicast, we could say that = just as a port that is down processes certain L2 control frames, it = should also process frames coming with a well known IANA allocated = multicast MAC (which would be used by all micro-BFD sessions). If we = were to go with a unicast IP encapsulation, then we will have to let the = port that is down accept (i) all broadcast frames (ARP requests) (ii) = all packets coming with your own MAC (ARP replies) (iii) all IP packets = addressed to you. > [[Sasha]] IMHO what you really say is "Let's treat BFD as one more L2 = control protocol".. The problem (as I see it) is that there is a clear = definition of what consitutes L2 control protocols (given by IEEE 802 = and accepted by, say, MEF when it discusses tunneling of these = protocols). A multicast IP packet would not be ever recognized as such.=20= >=20 > Clearly, this is an order of magnitude worse than what = happens if we go with multicast IP encapsulation. >=20 > [[Sasha]] Sorry, but I do not see any difference - for the reasons = stated above. >=20 > =20 > If LACP is used on LAG members and micro-BFD sessions do not use = IP-based encapsulation, they can be activated once LACP brings the link = UP. =20 > =20 > [Manav] Yes. I think i had mentioned even earlier that BFD without IP = based encapsulation is perhaps the best. But that requires a well known = MAC from IEEE and a new Ether type. I am not sure how easy or complex = this is. > [[Sasha]] Neither do I, but it is worth trying IMHO. BTW, IETF already = has a block of MAC addresses allocated to it by IEEE 802 with IANA = distributing addresses within this block. So you probably need only a = new Ethertype, and these are usually reasonably easy to obtain. E.g., = MEF has easily got one for its CESoETH (MEF 8) protocol several years = ago. >=20 > =20 > BFD sessions that do not use IP encapsulation can be used even if LACP = is not used on LAG members. In this case they will interact directly = with the Aggregator rather than with LACP.=20 > [Manav] I am not sure i understand why having an IP encapsulation = precludes an implementation to directly interact with the Aggregator. In = fact, all control packets from the micro BFD session will ONLY interact = with the Aggregator, and never with LACP. > =20 > [[Sasha]] I suspect that this would create lots of conflicts because = Aggregator's understanding of the link status would be fed by two = conflicting sources: LACP session and micro-BFD session. >=20 > You've claimed that an IP-based encapsulation for micro-BFD that = uses unicast IP destination address and a dedicated UDP port (to = differentiate it from a 1-hop IPv4/IPv6 session) would will not work for = unnumbered IP interfaces. I think that this is incorrect because RFC = 5881 works for unnumbered P2P IP interfaces as fine as for numbered = ones. The relevant text is IMHO in Section 6 "Addressing issues" of RFC = 5881, and the only part of it that is relevant to P2P links says that = "the source address of a BFD Control packet MUST NOT be used to identify = the session". =20 > =20 > [Manav] I am more concerned about the destination IP address than the = source IP. What dest IP to you use? Even if you do manage to use a = 127/8, what dest MAC do you use? Do you use a well known L2 MAC address = for IP unicast based encaps. If Yes, then you need to get this from = IEEE. > =20 > [[Sasha]] What destination IP address do you use in RFC 5881? As for = MAC, LAG is assigned with its own MAC address (which may but does not = have to match MAC address of one of its member links), and, in the case = of IP over LAG, is learned via ARP. > =20 > Note that with multicast you dont need any L2 address allocation.=20 > Last but not least, I do not think that my proposals require = complicated coordination with IEEE 802.1AX. LAG-related state machines = are well defined, all you need is feeding existing some inputs into them = from micro-BFD rather than from the physical layer, and activating = micro-BFD sessions from them (which is a minor change IMO). However, to = this extent coordination with IEEE 802.1AX seems unavoidable unless you = explicitly declare that LAG with micro-BFD sessions is mutually = exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the = consequences of such a decision. =20 > =20 > [Manav] I am not worried about feeding state from the micro BFD = sessions to the LAG module - thats an implementation specific issue. = What i am concerned about is getting their approval for a new ether = type, L2 mac addr and new encap that we want.=20 > =20 > [[Sasha]] I'd say you the only way to find out would be to try? > =20 > Cheers, Manav > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >=20 -- Marc Binderberger --Apple-Mail-2-65614646 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Alexander,

now I found the time to read this as well = ... few questions to you:

- it seems that = defining the "bringing down" of a LAG member link via BFD micro session = is mainly a matter of referring to the particular state(-changes) in = aggregation control of 802.1AX ?  So no changes required within = 802.1AX definition itself, in your opinion?

- = the "bringing up" though does require changes in 802.1AX, if we want to = make it dependent on BFD?  I wonder already about basics like "do I = bring up LACP first and then BFD? Or vice versa? Or both in = parallel?". 

Btw, the customers I know = largely do use both, LACP and the BFD on LAG member links. LACP does the = right job to organize a bundle in general - it's just a bit slow. Which = also means when LACP is configured one probably wants both protocols = signalling their "go" before a link it brought into forwarding (_if_ you = want to make it depending on BFD, I = mean).


Alexander, you = mentioned:

The problem (as I see it) is that there is a clear = definition of what consitutes L2 control protocols (given by IEEE 802 = and accepted by, say, MEF when it discusses tunneling of these = protocols). A multicast IP packet would not be ever recognized as = such. 

- do you have a pointer to = the definition?

- you see this as a problem for = the case when BFD is used to "bring up", correct? Once the LAG is up = then using e.g. IPv4 or IPv6 related multicast MAC is fine in your = opinion?


About approvals from = 802.1AX and a draft that requires such approvals my opinion is it's the = wrong direction. Faster LACP implementation(s) exist - proprietary, I = assume - and if this hasn't been managed to be standardized yet then I = don't see why BFD should have any better = chance.

As much as I like the insight I gained = from this discussion between Alexander and Manav, I wonder how much of = this can be standardized in an IETF draft. Maybe we should define the = core mechanics of BFD on Lag member links (BLM for short) and make the = result of this 802.1AX centric discussion a section of how BLM could be = used with LAG, marked as = informal?


Regards, = Marc



On = 2011-12-16, at 12:12 , Alexander Vainshtein wrote:

Manav,
Lots of thanks for a prompt response.
 
Please see some comments inline  in = green italics below (with snipped parts when we seem to be = aligned).
 
Regards,
     Sasha
 
From: Bhatia, Manav (Manav) = [manav.bhatia@alcatel-lucent.com]
Sent: Friday, December 16, 2011 10:29 AM
To: Alexander Vainshtein
Cc: rtg-bfd@ietf.org
Subject: RE: BFD on LAG interfaces

Hi Sasha,
 
Thanks for your comments.
 
My response's inline.
 
... = snipped...

 You've said = that the member link should come UP as soon as the micro BFD session gets = established and, based on this, you reject LACP (if used) as = the mechanism for bringing the member link UP - Will it not take LACP long (at least 1 secs) to bring = the link up? I see two issues with this logic:

    • Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD = control packet per second (as explained in RFC 5880, Section 6.8.3). = Hence I would expect that bringing UP a failed member link via the = 5880-compliant micro-BFD session would take approximately as long as it would with LACP using a = 1' timer. Or do you worry about LACP with 30' = timers?  
  1. [Manav] If LACP = uses its default periodic timer of 30 secs, then that screws up = BFD. This means that BFD on LAG will only work if the = administrator manually changes the default LACP timer from 30s to 1sec. I am not = very comfortable with a solution that hinges on all administrators = manually configuring something correctly for it to work - to me this is = a very tenuous design.

[[Sasha]] I see = your point, but I do not think it is a very serious issue. = Misconfiguration can kill lots of protocols, and BFD is not really an = exception.

 
          = [Manav] This also necessitates running LACP along with BFD. I am ok if = LACP can run with BFD. I am not sure if i am ok with mandating LACP to = run with BFD. But then this is a personal choice ..
[[Sasha]] LACP is = only required if you insist on running BFD in an IP encapsulation.
    • If LACP is used on a LAG member that has been brought DOWN by a = micro-BFD session, it has to be involved i = bringing the link UP anyway: it must declare the local link state as = "Collecting" and then go thru some stages until the link is recognized as "Collecting" and = "Distributing" by both peers. This would also take some time (probably a = few hundreds of milliseconds) because LACP is a slow protocol. Attempts = to bypass the LACP procedures for bringing the link UP could easily run into serious interoperability problems - unless you = are ready to say that LAG with LACP and LAG with per-link BFD are = mutually exclusive. 
Which entity should activate the micro-BFD session, and when? I've = probably not expressed my position clearly enough, hence your = comment  I think you meant that = the micro BFD session would wait for the member link to come up before it gets = restarted. Why should it wait for the entire LAG to come up again? = In fact in some cases the LAG will not even go DOWN when a micro BFD = session goes down. What I've really meant is the following:
    • If micro-BFD sessions use IP-based encapsulations, LAG (which is the = interface that IP sees) MUST be UP before they can be activated. As I've = noted, if LAG is down it could safely drop any IP packets it receives. = You seem to have accepted this point.  
     
    [Manav] = LAG can only be UP, if there is atleast one component link that is = alive. Yes what you have described is a deadlock. But this is more = so with Unicast encapsulation. With multicast, we could say that just as a port that is down processes = certain L2 control frames, it should also process frames coming = with a well known IANA allocated multicast MAC (which would be used by = all micro-BFD sessions). If we were to go with a unicast IP encapsulation, then we will have to let the port that is down accept = (i) all broadcast frames (ARP requests) (ii) all packets coming with = your own MAC (ARP replies) (iii) all IP packets addressed to = you.

[[Sasha]] IMHO what you really say is "Let's treat BFD = as one more L2 control protocol".. The problem (as I see it) is that = there is a clear definition of what consitutes L2 control protocols (given by IEEE 802 = and accepted by, say, MEF when it discusses tunneling of these = protocols). A multicast IP packet would not be ever recognized as = such. 

       &nb= sp; Clearly, this is an order of magnitude worse = than what happens if we go with multicast IP = encapsulation.

[[Sasha]] Sorry, but I do not see any difference - for = the reasons stated above.

 
    • If LACP is used on LAG members and micro-BFD sessions do not use = IP-based encapsulation, they can be activated once LACP brings the link = UP.  
     
    [Manav] = Yes. I think i had mentioned even earlier that BFD without IP based = encapsulation is perhaps the best. But that requires a well known MAC = from IEEE and a new Ether type. I am not sure how easy or complex this is.

[[Sasha]] Neither do I, but it is worth trying IMHO. = BTW, IETF already has a block of MAC addresses allocated to it by IEEE 802 with = IANA distributing addresses within this block. So you probably need only = a new Ethertype, and these are usually reasonably easy to obtain. E.g., = MEF has easily got one for its CESoETH (MEF 8) protocol several years ago.

 
  • BFD sessions that do not use IP encapsulation can be used even if = LACP is not used on LAG members. In this case they will interact directly with the Aggregator rather than = with LACP. 
  1. [Manav] I = am not sure i understand why having an IP encapsulation precludes an = implementation to directly interact with the Aggregator. In fact, all = control packets from the micro BFD session will ONLY interact with the Aggregator, and never with = LACP.
 

[[Sasha]] I suspect that this would create lots of = conflicts because Aggregator's understanding of the link status would be = fed by two conflicting sources: LACP session and micro-BFD session.

  1.       You've claimed that an IP-based encapsulation for micro-BFD that = uses unicast IP destination address and a = dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6 session) = would will not work for unnumbered IP = interfaces. I think that this is incorrect because RFC 5881 works = for unnumbered P2P IP interfaces as fine as for numbered ones. = The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is = relevant to P2P links says that "the source address of a BFD Control packet MUST = NOT be used to identify the session".  
 
[Manav] I am more concerned about the = destination IP address than the source IP. What dest IP to you use? = Even if you do manage to use a 127/8, what dest MAC do you use? Do you use a well known L2 MAC address for IP unicast based encaps. If Yes, = then you need to get this from IEEE.
 
[[Sasha]] What destination IP address do you use in = RFC 5881? As for MAC, LAG is assigned with its own MAC address (which may but does not have to match MAC address of one of its = member links), and, in the case of IP over LAG, is learned via = ARP.
 
Note = that with multicast you dont need any L2 address = allocation. 
  1. Last but not least, I do not think that my proposals require = complicated coordination with IEEE 802.1AX. LAG-related state machines = are well defined, all you need is feeding existing some inputs into them = from micro-BFD rather than from the physical layer, and activating micro-BFD sessions from = them (which is a minor change IMO). However, to this extent = coordination with IEEE 802.1AX  seems unavoidable unless you = explicitly declare that LAG with micro-BFD sessions is mutually = exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the consequences = of such a decision.  
 
[Manav] I am not worried about feeding = state from the micro BFD sessions to the LAG module - thats an = implementation specific issue. What i am concerned about is getting = their approval for a new ether type, L2 mac addr and new encap that we = want. 
 
[[Sasha]] I'd say you the only way to find out would = be to try?
 
Cheers, = Manav

This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof.


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

= --Apple-Mail-2-65614646-- From Alexander.Vainshtein@ecitele.com Sat Dec 17 09:16:04 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 E1E8721F8726 for ; Sat, 17 Dec 2011 09:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTVaM1LIrVjH for ; Sat, 17 Dec 2011 09:16:03 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 6CF6B21F86A4 for ; Sat, 17 Dec 2011 09:16:02 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-21.messagelabs.com!1324142158!2340974!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 11113 invoked from network); 17 Dec 2011 17:15:58 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-4.tower-21.messagelabs.com with SMTP; 17 Dec 2011 17:15:58 -0000 X-AuditID: 93eaf2e8-b7f276d000000ac3-f4-4eeccf58508d Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 98.FB.02755.85FCCEE4; Sat, 17 Dec 2011 19:20:24 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sat, 17 Dec 2011 19:15:56 +0200 From: Alexander Vainshtein To: Gregory Mirsky Date: Sat, 17 Dec 2011 19:15:57 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7wABf3ME0AA9Aj4AAGKKfiAAw0QxAAMzGjDQ== Message-ID: References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69CILPTMAIL02e_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTXUwTWRj1zpQyIGOGYuHS+DNe0cSfkiJrrNEaE/8fRFGigJt1x+m1nWw7 U2cGtT4oapRYEoMiojVGjIiKGowPgkGNsnFXazdsTHCNlGUTSFSs+yAaEVjZmY4iL76d+51z zzm5+S5FWqqTbZQgqlgWOR8yp5qq+969txe3xwscVdU5zpe9IeDsH74FlhKrBz90mFfX138i 1hOl5WAxJ4qSyqmYdWOFd6H1srCT44OIFdwulIfYgI/jsR+LqgtxgQAW3WhJ6mJtKIgsFnnJ LYgeF1qzcZ3d6Zy/0J6Hlsycnpe/KLXIKygstvs5wcf6saJwHsxqE72h6MZudrsks6oXs/LP 1aT33kANERjYT+xuvnENlIPwCxACKRRkfoBNv5/5gjPhn383mXVsYVoBvNCyPARSNXwSwIGa eLJOmBkXvHm1KyGayDhgZ8MlUsckMwseeNSf0JiYGbDybTQxz2AQbKwaTDb002FzVzcw8CbY XBlJ+NBMIXx/8EySEfYXCWMdHaYQoKgUphgebk3ogVbuY+QaYWRlwRe95wijNAPr77STBrbC 1z2fkwy9FcYqmoBuQzISjA/KRlQ6fHy612TIs+GDy89NVSAzPMY1/O1GeMwNQ5ILn9ecMBt4 Dmw4/4Y0sB2e+txmGjuvA8mNIFvwBdRtfo9jnl0qU3MxL6jYh3N5yX8TGPvzqgV0Rme1AYYC KI1mK94UWJK4nUrQ3wayKQJZae5hvMAyYZvkDno5xbtVLvNhpQ1AikQT6ZmbNY52c8E9WJa+ Uiu09z9G2sbzkr4H6tZ8h+P7B5RFV/LxtRbGo23nLxgHsPzVZxJFIUh3/qFFpMvYg3dvF3zq N5qgUvQaaVqNp7qGVgKcXxE8Bh8B+dTd/o9RQL2uHYoCi0mURGzLoi/qUkaXesvEUTf9L+0b GRnpA1naM2QYhmnaHo/69WlRhBZ1tDARpf2lUcpWDoLhC7WR88UrJ9unBdRIKZsz53pPNCmj q/QUV3fbNsXb0Dn8btda9OzKoRntT6yvHi+LpZv3pQwPPOjKaf23oWpHydwV93sXHDXbxrf8 E1/1kM8Wbvw4lbTGK0qKP9T99GtRYXfJb44Ng0fedh/wHHeGPAuHKs/OfrIlNjRu70jsv0sY mRQvlzeblBXufzp3IBwmBAAA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 17:16:05 -0000 --_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69CILPTMAIL02e_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Dear Greg, To clarify one point: The text you've quoted refers to IANA (and not to the IEEE MAC addresses' re= gistry) because IETF "owns" a pre-allocated block of MAC addresses, and spec= ific allocations from this block are made by IANA. Whether we need a dedicated Ethertype for BFD over Ethernet for micro-BFD se= ssions is a separate issue. My 2c, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Friday, December 16, 2011 6:45 PM To: Alexander Vainshtein; Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Dear Sasha, Manav, et al., I agree with Sasha that non-IP encapsulation of BFD over Ethernet is attaina= ble and will refer to draft-fbb-mpls-tp-ethernet-addressing-00 that requests= allocation multicast MAC by IANA: "IANA is requested to allocate an Ethernet Multicast Address from the Ethern= et Multicast Addresses table in the ethernet-numbers registry for use by MPL= S-TP LSRs over point-to-point links as described in Section 2." Regards, Greg ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf O= f Alexander Vainshtein Sent: Friday, December 16, 2011 3:13 AM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Manav, Lots of thanks for a prompt response. Please see some comments inline in green italics below (with snipped parts= when we seem to be aligned). Regards, Sasha ________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Friday, December 16, 2011 10:29 AM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Hi Sasha, Thanks for your comments. My response's inline. ... snipped... You've said that the member link should come UP as soon as the micro BFD se= ssion gets established and, based on this, you reject LACP (if used) as the= mechanism for bringing the member link UP - Will it not take LACP long (at= least 1 secs) to bring the link up? I see two issues with this logic: * Once the micro-BFD session goes DOWN, it falls back to sending 1 BFD= control packet per second (as explained in RFC 5880, Section 6.8.3). Hence= I would expect that bringing UP a failed member link via the 5880-compliant= micro-BFD session would take approximately as long as it would with LACP us= ing a 1' timer. Or do you worry about LACP with 30' timers? * 1. [Manav] If LACP uses its default periodic timer of 30 secs, then that s= crews up BFD. This means that BFD on LAG will only work if the administrator= manually changes the default LACP timer from 30s to 1sec. I am not very com= fortable with a solution that hinges on all administrators manually configur= ing something correctly for it to work - to me this is a very tenuous design= . [[Sasha]] I see your point, but I do not think it is a very serious issue. M= isconfiguration can kill lots of protocols, and BFD is not really an excepti= on. [Manav] This also necessitates running LACP along with BFD. I am o= k if LACP can run with BFD. I am not sure if i am ok with mandating LACP to= run with BFD. But then this is a personal choice .. [[Sasha]] LACP is only required if you insist on running BFD in an IP encaps= ulation. 1. * If LACP is used on a LAG member that has been brought DOWN by a micr= o-BFD session, it has to be involved i bringing the link UP anyway: it must= declare the local link state as "Collecting" and then go thru some stages u= ntil the link is recognized as "Collecting" and "Distributing" by both peers= . This would also take some time (probably a few hundreds of milliseconds) b= ecause LACP is a slow protocol. Attempts to bypass the LACP procedures for b= ringing the link UP could easily run into serious interoperability problems= - unless you are ready to say that LAG with LACP and LAG with per-link BFD= are mutually exclusive. * Which entity should activate the micro-BFD session, and when? I've probably= not expressed my position clearly enough, hence your comment I think you m= eant that the micro BFD session would wait for the member link to come up be= fore it gets restarted. Why should it wait for the entire LAG to come up aga= in? In fact in some cases the LAG will not even go DOWN when a micro BFD ses= sion goes down. What I've really meant is the following: 1. * If micro-BFD sessions use IP-based encapsulations, LAG (which is the= interface that IP sees) MUST be UP before they can be activated. As I've no= ted, if LAG is down it could safely drop any IP packets it receives. You see= m to have accepted this point. [Manav] LAG can only be UP, if there is atleast one component link that is a= live. Yes what you have described is a deadlock. But this is more so with Un= icast encapsulation. With multicast, we could say that just as a port that i= s down processes certain L2 control frames, it should also process frames co= ming with a well known IANA allocated multicast MAC (which would be used by= all micro-BFD sessions). If we were to go with a unicast IP encapsulation,= then we will have to let the port that is down accept (i) all broadcast fra= mes (ARP requests) (ii) all packets coming with your own MAC (ARP replies) (= iii) all IP packets addressed to you. [[Sasha]] IMHO what you really say is "Let's treat BFD as one more L2 contro= l protocol".. The problem (as I see it) is that there is a clear definition= of what consitutes L2 control protocols (given by IEEE 802 and accepted by,= say, MEF when it discusses tunneling of these protocols). A multicast IP pa= cket would not be ever recognized as such. Clearly, this is an order of magnitude worse than what happens if w= e go with multicast IP encapsulation. [[Sasha]] Sorry, but I do not see any difference - for the reasons stated ab= ove. 1. * If LACP is used on LAG members and micro-BFD sessions do not use IP-= based encapsulation, they can be activated once LACP brings the link UP. [Manav] Yes. I think i had mentioned even earlier that BFD without IP based= encapsulation is perhaps the best. But that requires a well known MAC from= IEEE and a new Ether type. I am not sure how easy or complex this is. [[Sasha]] Neither do I, but it is worth trying IMHO. BTW, IETF already has a= block of MAC addresses allocated to it by IEEE 802 with IANA distributing a= ddresses within this block. So you probably need only a new Ethertype, and t= hese are usually reasonably easy to obtain. E.g., MEF has easily got one for= its CESoETH (MEF 8) protocol several years ago. * BFD sessions that do not use IP encapsulation can be used even if LACP= is not used on LAG members. In this case they will interact directly with t= he Aggregator rather than with LACP. 1. [Manav] I am not sure i understand why having an IP encapsulation precl= udes an implementation to directly interact with the Aggregator. In fact, al= l control packets from the micro BFD session will ONLY interact with the Agg= regator, and never with LACP. [[Sasha]] I suspect that this would create lots of conflicts because Aggrega= tor's understanding of the link status would be fed by two conflicting sourc= es: LACP session and micro-BFD session. 1. You've claimed that an IP-based encapsulation for micro-BFD that= uses unicast IP destination address and a dedicated UDP port (to differenti= ate it from a 1-hop IPv4/IPv6 session) would will not work for unnumbered IP= interfaces. I think that this is incorrect because RFC 5881 works for unnum= bered P2P IP interfaces as fine as for numbered ones. The relevant text is I= MHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it th= at is relevant to P2P links says that "the source address of a BFD Control p= acket MUST NOT be used to identify the session". [Manav] I am more concerned about the destination IP address than the source= IP. What dest IP to you use? Even if you do manage to use a 127/8, what des= t MAC do you use? Do you use a well known L2 MAC address for IP unicast base= d encaps. If Yes, then you need to get this from IEEE. [[Sasha]] What destination IP address do you use in RFC 5881? As for MAC, LA= G is assigned with its own MAC address (which may but does not have to match= MAC address of one of its member links), and, in the case of IP over LAG, i= s learned via ARP. Note that with multicast you dont need any L2 address allocation. 1. Last but not least, I do not think that my proposals require complicate= d coordination with IEEE 802.1AX. LAG-related state machines are well define= d, all you need is feeding existing some inputs into them from micro-BFD rat= her than from the physical layer, and activating micro-BFD sessions from the= m (which is a minor change IMO). However, to this extent coordination with I= EEE 802.1AX seems unavoidable unless you explicitly declare that LAG with m= icro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.= 1AX - and bear all the consequences of such a decision. [Manav] I am not worried about feeding state from the micro BFD sessions to= the LAG module - thats an implementation specific issue. What i am concerne= d about is getting their approval for a new ether type, L2 mac addr and new= encap that we want. [[Sasha]] I'd say you the only way to find out would be to try? Cheers, Manav This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69CILPTMAIL02e_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable
Dear Greg,
To clarify one point:
 
The text you've quoted refers to IANA (and not to the IEEE MAC addresses' registry) because= IETF "owns" a pre-allocated block of MAC addresses, a= nd specific allocations from this block are made by IANA.
 
Whether we need a dedicated Etherty= pe for BFD over Ethernet for micro-BFD sessions is a separate= issue.
 
My 2c,
     Sasha
 
 
 
From: Gregory Mirs= ky [gregory.mirsky@ericsson.com]
Sent: Friday, December 16, 2011 6:45 PM
To: Alexander Vainshtein; Bhatia, Manav (Manav)
Cc: rtg-bfd@ietf.org
Subject: RE: BFD on LAG interfaces

Dear Sasha, Manav, et al.,
I agree with Sasha that non-IP encapsulation of BFD over Ethernet is attaina= ble and will refer to draft-fbb-mpls-tp-ethernet-addressing-00 that requests= allocation multicast MAC by IANA:
"IANA is requested to allocate an Ethernet Multicast Address from the E= thernet Multicast Addresses table in the ethernet-numbers registry for use b= y MPLS-TP LSRs over point-to-point links as described in Section 2."

Regards,
Greg

From: rtg-bfd-bounces@ietf.org [mail= to:rtg-bfd-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Friday, December 16, 2011 3:13 AM
To: Bhatia, Manav (Manav)
Cc: rtg-bfd@ietf.org
Subject: RE: BFD on LAG interfaces

Manav,
Lots of thanks for a prompt response.
 
Please see some comments inline  in green italics below (with snipped p= arts when we seem to be aligned).
 
Regards,
     Sasha
 
From: Bhatia, Mana= v (Manav) [manav.bhatia@alcatel-lucent.com]
Sent: Friday, December 16, 2011 10:29 AM
To: Alexander Vainshtein
Cc: rtg-bfd@ietf.org
Subject: RE: BFD on LAG interfaces

Hi Sasha,
 
Thanks for your comments.
 
My response's inline.=
 
... snipped...

 <= /span>You've said that the member link should come UP as soon as= the micro BFD session gets established and, based on t= his, you reject LACP (if used) as the mechanism for bringing the member= link UP - Will it not take LACP long (at least 1 secs) to bring the l= ink up? I see two issues with this logic:

    • Once the micro-BFD session goes DOWN, it= falls back to sending 1 BFD control packet per second (as explained in RFC= 5880, Section 6.8.3). Hence I would expect that bringing UP a failed member= link via the 5880-compliant micro-BFD session would take approximately as long as it would with LACP using a 1' t= imer. Or do you worry about LACP with 30' timers?  
  1. [Manav] If LACP uses= its default periodic timer of 30 secs, then that screws up BFD. T= his means that BFD on LAG will only work if the administrator manually changes the default LACP timer from 30s to 1sec. I am not ver= y comfortable with a solution that hinges on all administrators manually con= figuring something correctly for it to work - to me this is a very tenuous d= esign.

[[Sasha]] I see your point, but I do not think it is a very= serious issue. Misconfiguration can kill lots of protocols, and BFD is not= really an exception.

 
          [Manav]= This also necessitates running LACP along with BFD. I am ok if LACP can run= with BFD. I am not sure if i am ok with mandating LACP to run with BFD. But= then this is a personal choice ..
[[Sasha]] LACP is only required if you insist on= running BFD in an IP encapsulation.
    • If LACP is used on a LAG member that has= been brought DOWN by a micro-BFD session, it has to be involved i bringing the link UP anyway: it must declare the local link= state as "Collecting" and then go thru some stages until the link is recognized as "Collecting" and &quo= t;Distributing" by both peers. This would also take some time (probably= a few hundreds of milliseconds) because LACP is a slow protocol. Attempts t= o bypass the LACP procedures for bringing the link UP could easily run into serious interoperability problems - unless you are= ready to say that LAG with LACP and LAG with per-link BFD are mutually excl= usive. 
Which entity should activate the micro-B= FD session, and when? I've probably not expressed my position clearly enough= , hence your comment =  I think you meant that the micro BFD session would wait for the member link to come up before it gets restarted.&nb= sp;Why should it wait for the entire LAG to come up again? In fact in some c= ases the LAG will not even go DOWN when a micro BFD session goes down. What I've really meant is the following:
    • If micro-BFD sessions use IP-based en= capsulations, LAG (which is the interface that IP sees) MUST be UP befo= re they can be activated. As I've noted, if LAG is down it could safely drop= any IP packets it receives. You seem to have accepted this point.  =
     
    [Manav] LAG can only be UP, if there is atleast one compo= nent link that is alive. Yes what you have described is a deadlock. But= this is more so with Unicast encapsulation. With multicast, we could say that just as a port that is down processes certain&= nbsp;L2 control frames, it should also process frames coming with a well kno= wn IANA allocated multicast MAC (which would be used by all micro-BFD sessio= ns). If we were to go with a unicast IP encapsulation, then we will have to let the port that is down accept (i)= all broadcast frames (ARP requests) (ii) all packets coming with your own M= AC (ARP replies) (iii) all IP packets addressed to you.

[[Sasha]] IMHO what you r= eally say is "Let's treat BFD as one more L2 control protocol".. T= he problem (as I see it) is that there is a clear definition of what consitutes L2 control protocols (given by IEEE 802 and a= ccepted by, say, MEF when it discusses tunneling of these protocols). A mult= icast IP packet would not be ever recognized as such. 

     =     Clearly, this is an order= of magnitude worse than what happens if we go with multicast IP encapsulati= on.

[[Sasha]] Sorry,= but I do not see any difference - for the reasons stated above.

 

    • If LACP is used on LAG members and micro-= BFD sessions do not use IP-based encapsulation, they can be activated once L= ACP brings the link UP.  
     
    [Manav] Yes. I think i had mentioned even earlier that BFD wit= hout IP based encapsulation is perhaps the best. But that requires a well kn= own MAC from IEEE and a new Ether type. I am not sure how easy or complex this is.

[[Sasha]] Neithe= r do I, but it is worth trying IMHO. BTW, IETF already has a block of MAC addresses allocated to it by IEEE 802 with IANA= distributing addresses within this block. So you probably need only a new E= thertype, and these are usually reasonably easy to obtain. E.g., MEF has eas= ily got one for its CESoETH (MEF 8) protocol several years ago.

 

  • BFD sessions that do not use IP encapsula= tion can be used even if LACP is not used on LAG members. In this case they will interact directly with the Aggregator rather than= with LACP. 
  1. [Manav] I am not sure i understand why having an IP encapsulati= on precludes an implementation to directly interact with the Aggregator. In= fact, all control packets from the micro BFD session will ONLY interact with the Aggregator, and never with LACP.

 

[[Sasha]] I suspect that= this would create lots of conflicts because Aggregator's understanding of t= he link status would be fed by two conflicting sources: LACP session and micro-BFD session.

  1.       You've claimed that an IP-based encapsulation= for micro-BFD that uses unicast IP destination ad= dress and a dedicated UDP port (to differentiate it from a 1-hop IPv4/IPv6 s= ession) would will not work for unnumber= ed IP interfaces. I think that this is incorrect because RFC 5881 wor= ks for unnumbered P2P IP interfaces as fine as for numbered ones.= The relevant text is IMHO in Section 6 "Addressing issues" of RFC 5881, and the only part of it that is= relevant to P2P links says that "the source address of a BFD Control packet MUST NOT= be used to identify the session". &n= bsp;
 
[Manav] I am more concerned about the destination IP= address than the source IP. What dest IP to you use? Even if you do ma= nage to use a 127/8, what dest MAC do you use? Do you use a well known L2 MAC address for IP unicast based encaps. If Yes, then y= ou need to get this from IEEE.
 
<= span class=3D"160165907-16122011">[[Sasha]] What destination IP address do you use in RFC 5881? As= for MAC, LAG is assigned with its own MAC address (which may but does not have to match MAC address of one of its mem= ber links), and, in the case of IP over LAG, is learned via ARP.=
 
Note that with multicast you dont need any L2 address allocati= on. 
  1. Last but not least, I do not think that m= y proposals require complicated coordination with IEEE 802.1AX. LAG-related= state machines are well defined, all you need is feeding existing some inpu= ts into them from micro-BFD rather than from the physical layer, and activating micro-BFD sessions from them (= which is a minor change IMO). However, to this extent coordination= with IEEE 802.1AX  seems unavoidable unless you explicitly declare tha= t LAG with micro-BFD sessions is mutually exclusive with one defined by IEEE 8023ad/802.1AX - and bear all the consequences of= such a decision.  
 
[Manav] I am not worried about feeding state from the mic= ro BFD sessions to the LAG module - thats an implementation specific issue.= What i am concerned about is getting their approval for a new ether type, L2 mac addr and new encap that we want. = ;
 
[[Sasha]] I'd= say you the only way to find out would be to try?=
 
Cheers, Manav

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof.

--_000_A3C5DF08D38B6049839A6F553B331C76011248A1E69CILPTMAIL02e_-- From Alexander.Vainshtein@ecitele.com Sat Dec 17 11:22:56 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 85C5D21F8AD8 for ; Sat, 17 Dec 2011 11:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.613 X-Spam-Level: X-Spam-Status: No, score=-4.613 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t16fX7DHN3XG for ; Sat, 17 Dec 2011 11:22:55 -0800 (PST) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 4EB4721F8AD1 for ; Sat, 17 Dec 2011 11:22:55 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1324149773!5906083!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 6453 invoked from network); 17 Dec 2011 19:22:54 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-174.messagelabs.com with SMTP; 17 Dec 2011 19:22:54 -0000 X-AuditID: 93eaf2e8-b7f276d000000ac3-82-4eeced1861cb Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 7E.6C.02755.81DECEE4; Sat, 17 Dec 2011 21:27:20 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 17 Dec 2011 21:22:52 +0200 From: Alexander Vainshtein To: Marc Binderberger Date: Sat, 17 Dec 2011 21:22:50 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy8ppMk+dUg7VBNQc2hhkDC1MCDMAARxu5wAACqssA= Message-ID: References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> <4E356AD7-0E1E-448E-B6E9-8D357F1AA30F@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1255" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0gUURjl7syuozk17Wp7VwqmiYweW2sWTY8tIyF7mfYuihp3bjtTu7PL zBgZRBJFkRS9IRMrWyp8JD3oRYVJCW5SZgVmqUESrbsh9MCKymYcM/t37ne+c75zZ75LYNYO SwohSiqSJc7HWBLwY52fvjjhx1i2q6V7NNtYZWNL2trM7OkXPRj7+ecNkIFn7X1/z5y15+FH c1Yo9N2UtbeiCM/B1xWCWZwkBVRORTSPFI+byZHFbZyngKFF3s2kMXTQx3mQH0mqm+GCQSTx zOyEWVpRlGgkeQK8KHndzILlS50sO3W6M42ZnToqLX1mwgpBVGjk9HOij/YjReG8iNYqemiJ Rzy9OSDTqoBoedMxTCirrDcFr9HbI9H9WCGodxwA8QSkpsBnJ+9hBh4GG9uqLQdAAmGlbgP4 vLSo73AcwFhTu0XvslBueLWitRcnUaNha7QW6Bij9gN48u0yHeNa/fGv7l5XG8XA8sM/4oz+ UfBmazsw8Az4LhzpxSSVC7tKakw6tlL3MXi6BeoYaIm6w5Umw98OWzrOmIykFAzdfdqXOhlG 3v02G/3J8M2+6r48Lvjk5pU4A4+HF85FMWPWUFh/qgM3tA744FIzfhgMKx4woniAvHiAvHiA /CzAy4FD9AXVPL/XNdkZyFcnIo+oIh+a6An4rwJjXz7cAq8bxtYCigBMIknvi2Zbzdw2pcBf CxyEiUkmp0Ri2dbBeQG+QOAUYaOc70NKLYAExiSRqas1juS5gh1IDvylWO3rHsFSBnkC+k9W N6a7XP8dGDtZ5IktsVJebdu2IhRE8l/pcIJgIHkiqrkOlZEXbd8s+tR/tImI1ycnapMf6T2k EuT8iug1+DAYmWInL+gEpRNCvtSv1R/Hrp6enk5g1+5pIx16V6K2hf3qTs3YpBkfyu011l5C P5VSCMx0mXDw2tzwmPYh3y+79sQyLtry4DgAdp8fmZQaml9NlM2x3cl07Frlaxz8bWdDsOtt 7svbTa9Q87z59jjz9EX3J2Qmh2+t5I/vWHtoS0P88vWfVpANP65HH09auHjDJel5By80ks3D p7FNGWsyN+VUTR1Rlz65dMvXLnbh0bpQpIbBFYFLG4fJCvcHrQq0ZfcDAAA= Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 19:22:56 -0000 Resending as plain text and clipping most of the "long tail" to fit the 40K= limit... Regards, Sasha From: Alexander Vainshtein Sent: Saturday, December 17, 2011 9:15 PM To: 'Marc Binderberger' Cc: rtg-bfd@ietf.org; Bhatia, Manav (Manav); Mach Chen Subject: RE: BFD on LAG interfaces Dear Marc, Lots of thanks for =A0prompt and detailed responses. Regarding the pointer to what constitutes a Layer 2 control Protocol:=A0 MEF= 10.2, Section 6.5.1.4 states that frames with Destination MAC addresses list= ed in a below are L2CP frames: 01-80-C2-00-00-00 thru 01-80-C2-00-00-0F - bridge block of protocols 01-80-C2-00-00-20 thru 01-80-C2-00-00-2F - GARP block of protocols 01080-C2-00-00-10 - all Bridge= s protocol This definitely does not include destination MAC addresses from the IETF blo= ck. Regarding the interaction between LACP and micro-BFD session on a given memb= er link of LAG: I think that this should follow the scheme in Section 4.1 of RFC 5882 if we= treat LACP as the control protocol that uses a micro-BFD session to bring i= ts adjacency down. LACP definitely does not provide for signaling that both= peers are willing to establish a BFD session, hence it can safely bring its= adjacency UP and notify the Aggregator. This approach IMHO provides an unam= biguous and non-controversial answer to all specific questions with the indi= cations provided by the micro-BFD session just augmenting those provided by= the physical layer of the corresponding member link. Hopefully these notes clarify my position on the subject, My 2c, =A0=A0=A0=A0 Sasha Regards, =A0=A0=A0=A0 Sasha From: Marc Binderberger [mailto:marc@sniff.de] Sent: Saturday, December 17, 2011 12:28 PM To: Alexander Vainshtein; Bhatia, Manav (Manav); Mach Chen Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG interfaces Hello Alexander, now I found the time to read this as well ... few questions to you: - it seems that defining the "bringing down" of a LAG member link via BFD mi= cro session is mainly a matter of referring to the particular state(-changes= ) in aggregation control of 802.1AX ? =A0So no changes required within 802.1= AX definition itself, in your opinion? - the "bringing up" though does require changes in 802.1AX, if we want to ma= ke it dependent on BFD? =A0I wonder already about basics like "do I bring up= LACP first and then BFD? Or vice versa? Or both in parallel?".=A0 Btw, the customers I know largely do use both, LACP and the BFD on LAG membe= r links. LACP does the right job to organize a bundle in general - it's just= a bit slow. Which also means when LACP is configured one probably wants bot= h protocols signaling their "go" before a link it brought into forwarding (_= if_ you want to make it depending on BFD, I mean). Alexander, you mentioned: The problem (as I see it) is that there is a clear definition of what consti= tutes L2 control protocols (given by IEEE 802 and accepted by, say, MEF when= it discusses tunneling of these protocols). A multicast IP packet would not= be ever recognized as such.=A0 - do you have a pointer to the definition? - you see this as a problem for the case when BFD is used to "bring up", cor= rect? Once the LAG is up then using e.g. IPv4 or IPv6 related multicast MAC= is fine in your opinion? About approvals from 802.1AX and a draft that requires such approvals my opi= nion is it's the wrong direction. Faster LACP implementation(s) exist - prop= rietary, I assume - and if this hasn't been managed to be standardized yet t= hen I don't see why BFD should have any better chance. As much as I like the insight I gained from this discussion between Alexande= r and Manav, I wonder how much of this can be standardized in an IETF draft.= Maybe we should define the core mechanics of BFD on Lag member links (BLM f= or short) and make the result of this 802.1AX centric discussion a section o= f how BLM could be used with LAG, marked as informal? Regards, Marc ... snipped... This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Sat Dec 17 21:54:13 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 2A1C521F88B7 for ; Sat, 17 Dec 2011 21:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.819 X-Spam-Level: X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[MIME_QP_LONG_LINE=1.819, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhCc1EA5ic30 for ; Sat, 17 Dec 2011 21:54:12 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 2334521F88AB for ; Sat, 17 Dec 2011 21:54:11 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1324187647!7815271!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 22256 invoked from network); 18 Dec 2011 05:54:08 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-11.tower-216.messagelabs.com with SMTP; 18 Dec 2011 05:54:08 -0000 X-AuditID: 93eaf2e8-b7f276d000000ac3-d8-4eed81096653 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 9D.9E.02755.9018DEE4; Sun, 18 Dec 2011 07:58:33 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sun, 18 Dec 2011 07:54:06 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Sun, 18 Dec 2011 07:54:06 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy7JDMdtwrYU1s6Ql6C19OkiblgDAANUr7wABf3ME0AA9Aj4AAGKKfiAADntQAAWF4zmQ== Message-ID: References: , <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> , <7C362EEF9C7896468B36C9B79200D8350D026F1370@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F1370@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa2wMURjN3dnH7Oowtl17t6QZ17ssXSWWWsEfbUMfHpWQqLFz7Q67M5uZ qbSe9YoiRFUkbcSjLdEijYrWqwn1SAmxfpHSinivV7QSlKiZDlX/zv3OOfd838x3ScLebk4k eUHBksCGkNlmLIt1fHFbN3/ISrmxf6L3UHu7ydv5swHMNKRvf9VkSq+u/m7IMSwpBtNZQRAV VsEMh2W/D+VI/BrWX4QYnvMhD2IiIdaPw1hQfIiNRLDAoRm26WqRFxgs+EWOFwI+lLEg2+31 Tp7q9qAZI4d5UtNsC4O8zGB3mOVDTBjLMhvAjFrROhQ4zDErRYlRgpiRlpcRwXuvKy2R7YML Y7fOEMXgvGMXsJKQngTPtjYZdTwIRtvrzLuAjbTTFwHsKqkE+uEAgFUfr/SozLQP1p9qM2s4 QcWvz13qqRP0GLilpdOiYSM9AnaXtfXgeBrB2n1dFl0/DDa2PQU6zoNnP0dNGqboXFi75eCf 5IcEvPxlD6ERVnoZbOiq6TEDtb2vd04b9DAnbH1xxKC3TcPqK/cJHTvg2+e/TLreAZ/sqAO6 fhw8ernDrOOx8MSxd4QePBDeLn/xZ3wXvHbykXEfcFb0iajoY6/oY6/oYz8KjLXAxYciyopw IGWiWyxQxmM/r+AQHu8Xw/VA35Q3F8Dju2OaAU0CFEcl53zIspvYNXJRuBm4SANyUE/XqqX+ K0SuKMjKwXypIITlZgBJAiVQIxe/z7JTHFu0FkviX8qrfupSIrGfX9T+uJKfmpLy3wE5qd3+ 9/PsdEBdvdUYR7D01zqEJBGkPm9UEwdKOIALV/Ih5R9tIK1acpyaLG9SNZQcYcMyH9D5O2Bo opNapBG0RgQLhF6v9iw2dXd3x4BTnTOecmmqOHUle90x9WKDevHeXG0kWX0WvVRiMcg9PaA8 2pm0nuiw7HRcWtb80pVUM39jLP126rSmAVWfEq4q541LC43VaHJDXt0qMT3fWXrYzud55kct NS0tU5JKtg7PvHsk3mob1PjgUNqE5V/rk1sXoQzp3s65N79xD+4/m5ORPetH47rZx+vTrmWW lI8aPSlpW+mrqpt7vkevr9twHBnlIOtJJiSZ/Q07OeQO8QMAAA== 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: Sun, 18 Dec 2011 05:54:13 -0000 Manav hi, I apologize for a delayed response to your message. Please see some comments inline below. Regards, Sasha ________________________________________ From: Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Friday, December 16, 2011 1:40 PM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces > Hi Sasha, >> [Manav] I am more concerned about the destination IP >> address than the source IP. What dest IP to you use? Even if you do >> manage to use a 127/8, what dest MAC do you use? Do you use a well >> known L2 MAC address for IP unicast based encaps. If Yes, then you need >> to get this from IEEE. >> >> [[Sasha]] What destination IP address do you use in RFC 5881? As for >> MAC, LAG is assigned with its own MAC address (which may but does >> not have to match MAC address of one of its member links), and, >> in the case of IP over LAG, is learned via ARP. > > I don't think you do dynamic ARP over unnumbered interfaces. [[Sasha]] Why not? And in any case, unicast IP was supposed to run over the= LAG in question. So the destination MAC address (that of LAG itself) would be known in some w= ay. (If IP was not supposed to run over LAG in question, we could use the mechan= ism defined in draft-fbb-mpls-tp-ethernet-addressing-00). Do I miss something? >> [Manav] I am not worried about feeding state from the micro BFD sessions >> to the LAG module - that's an implementation specific issue. What i am >> concerned about is getting their approval for a new ether type, L2 mac >> addr and new encap that we want. >> >> [[Sasha]] I'd say you the only way to find out would be to try? > Sure, that can be done. I will include some text on direct encapsulation o= ver L2 (without IP/UDP headers) > in the next version. > Right now we have three encapsulation options for the micro-BFD sessions. > 1. Using multicast dest IP > 2. Using Unicast IP > 3. Direct encapsulation of the BFD packet without IP/UDP headers > I think its clear that there is value in implementing (3) as long as we ca= n get IEEE to part with some of its > treasure. What about (1) and (2)? I will raise a separate thread to discus= s the preferred IP > encapsulation scheme. [[Sasha]]. Raising a separate thread dealing with possible encapsulation(s)= of micro-BFD sessions looks right to me. Currently there are at least two groups of issues we're discuss= ing: architecture (relationships between Aggregator, LACP and micro-BFD) and encapsulation. IP-based encapsul= ation adds its own architectural issue but IMHO it cannot be considered unless the larger issue= s have been nailed down. > Regarding (1), I am sure someone on the list can illuminate us on what it= entails to get a well known MAC > and an Ether Type from IEEE for our purpose. This was done for TRILL recen= tly and I can ping the TRILL > folks on this, unless someone on this list already has this information,= and is kind enough to share it with us. [[Sasha]] I am repeating what Greg and I have already mentioned in this thre= ad: a new MAC address should be assigned by IANA from the block it holds from IEEE 802. A new Ethertype= is probably the preferred method, but it could be bypassed. One option (adm= ittedly a hack!) could be to run micro-BFD sessions in G-ACH encapsulations= defined for MPLS-TP. > Cheers, Manav This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From d3e3e3@gmail.com Sun Dec 18 07:30:33 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 73E9521F84CD for ; Sun, 18 Dec 2011 07:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.11 X-Spam-Level: X-Spam-Status: No, score=-102.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONFeMTIqzOEj for ; Sun, 18 Dec 2011 07:30:32 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8169E21F84C9 for ; Sun, 18 Dec 2011 07:30:32 -0800 (PST) Received: by laah2 with SMTP id h2so2145015laa.31 for ; Sun, 18 Dec 2011 07:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=WhOTDsoIf0LxLYGngKOTIX3PjUqykd+jRYB81vQHEDM=; b=tuiVJA9ipGwTVRhVOOJFXjYKBweFTuMxPm47BddJPqP2Cg0OcLp/DdpXmBiFBOCuaF K8ZcKWlFpNkulE6Pw5k3Tq0j0TTLr10I96RX6daE6DfEB23DBHInHZuryHIP/2pRwpkC hE9PXVSEQdYZnxhon4gWOsODSqcGhNBV7RMQs= Received: by 10.152.128.98 with SMTP id nn2mr999591lab.14.1324222231289; Sun, 18 Dec 2011 07:30:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.133.228 with HTTP; Sun, 18 Dec 2011 07:30:10 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F1370@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F1370@INBANSXCHMBSA1.in.alcatel-lucent.com> From: Donald Eastlake Date: Sun, 18 Dec 2011 10:30:10 -0500 Message-ID: Subject: Re: BFD on LAG interfaces To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 15:30:33 -0000 Hi, On Fri, Dec 16, 2011 at 6:40 AM, Bhatia, Manav (Manav) wrote: > Hi Sasha, > >... > > Right now we have three encapsulation options for the micro-BFD sessions. > > 1. Using multicast dest IP > 2. Using Unicast IP > 3. Direct encapsulation of the BFD packet without IP/UDP headers > > I think its clear that there is value in implementing (3) as long as we c= an get IEEE to part with some of its treasure. What about (1) and (2)? I wi= ll raise a separate thread to discuss the preferred IP encapsulation scheme= . > > Regarding (1), I am sure someone on the list can illuminate us on what it= entails to get a well known MAC and an Ether Type from IEEE for our purpos= e. This was done for TRILL recently and I can ping the TRILL folks on this,= unless someone on this list already has this information, and is kind enou= gh to share it with us. On getting a MAC address, I would recommend going through IANA as per RFC 5342. While it was not that hard to get a standards use multicast MAC address from the IEEE Registration Authority, it took a while. However, if you are using multicast destination IP, I'm not sure why you wouldn't just use the derived multicast MAC. In any case, for an Ethertype you pretty much just do an regular application but explain that it is for standards use and they zero out the amount due. See http://standards.ieee.org/develop/regauth/ethertype/ 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 > Cheers, Manav > From manav.bhatia@alcatel-lucent.com Sun Dec 18 07:42:43 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 DE64621F84F5 for ; Sun, 18 Dec 2011 07:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSxZPRzn26gv for ; Sun, 18 Dec 2011 07:42:43 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id D995721F84DB for ; Sun, 18 Dec 2011 07:42:42 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBIFgcNR015782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Dec 2011 09:42:40 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBIFgbC8025530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 18 Dec 2011 21:12:37 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sun, 18 Dec 2011 21:12:37 +0530 From: "Bhatia, Manav (Manav)" To: Donald Eastlake Date: Sun, 18 Dec 2011 21:12:35 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy9mf+7/uJIMB+xS3WQqUqmAdxqlgAAT2RQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F145D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D026F12AB@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F132F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D026F1370@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 15:42:44 -0000 Hi Donald, =20 > On getting a MAC address, I would recommend going through=20 > IANA as per RFC 5342. While it was not that hard to get a=20 > standards use multicast MAC address from the IEEE=20 > Registration Authority, it took a while. > However, if you are using multicast destination IP, I'm not=20 > sure why you wouldn't just use the derived multicast MAC. We're looking at an L2 MAC if we need to directly encapsulate the BFD packe= t (without IP/UDP headers) over the L2 header. >=20 > In any case, for an Ethertype you pretty much just do an=20 > regular application but explain that it is for standards use=20 > and they zero out the amount due. See=20 > http://standards.ieee.org/develop/regauth/ethertype/ Thanks! Cheers, Manav= From nobo@cisco.com Sun Dec 18 17:59:47 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 93D7C21F8B10 for ; Sun, 18 Dec 2011 17:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6y5-kzCnVBF for ; Sun, 18 Dec 2011 17:59:46 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E0C5B21F8B18 for ; Sun, 18 Dec 2011 17:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=3205; q=dns/txt; s=iport; t=1324259987; x=1325469587; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yP74ahpLBXHcflEWWjMgnNL7sFhwm7YYZkipoJVtiwE=; b=bS011UMzCHaqPiqtshuROs6neOXJZedVS7RntEf0mxeE2K/dDJ/7u452 2bCQw8BTmC834XdRmLBaYphbXb8Cm58hUtHQ430H8NgVF1GmnF6KXD9D+ g+5x9xJ9CactQB7iwyQxP4IAKItMUk4UZdS8aiH1VQvi8Ocxy3/OvY3hZ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACma7k6rRDoJ/2dsb2JhbABDq1qBBYFyAQEBAwESAR0KPwULAgEIIgYYBgFWAQEEARoah1iZAAGdVYshYwSINp8X X-IronPort-AV: E=Sophos;i="4.71,373,1320624000"; d="scan'208";a="21409191" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 19 Dec 2011 01:59:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBJ1xksT025953; Mon, 19 Dec 2011 01:59:46 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Dec 2011 17:59:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: BFD on LAG interfaces Date: Sun, 18 Dec 2011 17:59:44 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: Acy8FAtj01wL68RnSzuXO2EPxyGc6wB0xLUQ References: From: "Nobo Akiya (nobo)" To: "Marc Binderberger" , "Alexander Vainshtein" X-OriginalArrivalTime: 19 Dec 2011 01:59:46.0305 (UTC) FILETIME=[E1FBDF10:01CCBDF1] Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 01:59:47 -0000 Hello, Section 3.2. > A member link of the LAG is not used anymore for data forwarding when > the particular BFD session running over that link goes down. The > member link MUST be removed from the LAG. The BFD session for the > link remains, i.e. it is not deleted. It is not clear when BFD session should get deleted (nor created). With above statement, BFD session could remain even when operator decides to shut down a member, depending on how it's interpreted/implemented. When LACP is used, LMM will startup LACP only when interface is up. L2 check starts only when L1 check passes. Check is done from bottom layer upwards. Going by same idea, BFD session should only be created when L2 check passes (LACP), when L2 check is being used. If L2 check is not being used, then L1 check is required for BFD session to get created. Absence in L1/L2 check pass should cause corresponding BFD sessions to get deleted. > > 3. The situation when LAG goes down due to insufficient number of active > links must be reversible, i.e., the LAG must be able to go UP once this > condition disappears. >=20 > yes, I would prefer this ;-) >=20 > > Do these notes capture the problem space correctly? Or did I miss > something important? > > > > One point that is not clear to me is the timeframe for bringing > constituent links of a LAG up. I would expect that the requirements for > that could be much more relaxed (e.g., in order to avoid link flapping). > Is that correct? If it is, one possible implication is that it is possible > to use different mechanisms for bringing links DOWN and UP. To the best > of my understanding, this is how BFD is supposed to be used with routing > adjacencies today, i.e. BFD can bring the adjacency DOWN quite fast, but > it has to be brought UP by the appropriate routing protocol. >=20 > the draft allows this, section 3.2 "To avoid this deadlock ...". So using > BFD to bring down fast alone is covered. Now RFC5882, e.g. section 4.1, > mentions that waiting for BFD's Up notification may be useful. Thus we > allowed this in the draft as well. >=20 >=20 > [I skip the LACP, CFM part. We had this. Nothing wrong technically but > somehow customers push BFD teams to deliver] Generally speaking, when up/down use different methods, I've seen a system fall into continuous flap cycle. Down by BFD, up by protocol/LMM is one possible approach, and your draft wants to allow this for interoperability purpose. I can understand the need, but side effect can be nasty, and it (possible continuous flap) can be described? Section 4, first bullet. LAG will be taken down when BFD fails on sufficient members (LAG interface state will be down). LAG will come up potentially when BFD on sufficient members come up (LAG interface state will be up). This behavior implies that all applications will benefit (by monitoring LAG interface state) even if those applications do not configure BFD on LAG. Sure, one can configure applications with BFD over LAG, but that's not an absolute requirement for this model. Statements regarding this behavior will be beneficial to readers. Thanx, Nobo From marc@sniff.de Mon Dec 19 00:32:45 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 6B32021F8A4E for ; Mon, 19 Dec 2011 00:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+OlLmSgLHI4 for ; Mon, 19 Dec 2011 00:32:44 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02E21F84D8 for ; Mon, 19 Dec 2011 00:32:44 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CA98B2AA0F; Mon, 19 Dec 2011 08:32:41 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Mon, 19 Dec 2011 09:32:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> References: To: Nobo Akiya (nobo) X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 08:32:45 -0000 Hello Nobo, thanks for the comments. Let me check this with the new version we are = just preparing (almost done). And yes, a cleaner description when the creation/deletion is part of it. But I also think this is where Alexander's comment came from: without = some modifications in 802.1AX it will not be possible to lock the "going = UP" with BFD. Otherwise you always run into questions and issues - = starting LACP first? Or BFD first? Or both in parallel? > Generally speaking, when up/down use different methods, I've seen a > system fall into continuous flap cycle. Down by BFD, up by = protocol/LMM > is one possible approach, and your draft wants to allow this for > interoperability purpose. I can understand the need, but side effect = can > be nasty, and it (possible continuous flap) can be described? *sigh* yes ... maybe we should write a draft on flap dampening? :-) Let me go through our latest (internal) version if that addresses your = points. Thanks! REgards, Marc On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: > Hello, >=20 > Section 3.2. >=20 >> A member link of the LAG is not used anymore for data forwarding > when >> the particular BFD session running over that link goes down. The >> member link MUST be removed from the LAG. The BFD session for the >> link remains, i.e. it is not deleted. >=20 > It is not clear when BFD session should get deleted (nor created). = With > above statement, BFD session could remain even when operator decides = to > shut down a member, depending on how it's interpreted/implemented. = When > LACP is used, LMM will startup LACP only when interface is up. L2 = check > starts only when L1 check passes. Check is done from bottom layer > upwards. Going by same idea, BFD session should only be created when = L2 > check passes (LACP), when L2 check is being used. If L2 check is not > being used, then L1 check is required for BFD session to get created. > Absence in L1/L2 check pass should cause corresponding BFD sessions to > get deleted. >=20 >=20 >>> 3. The situation when LAG goes down due to insufficient number of > active >> links must be reversible, i.e., the LAG must be able to go UP once > this >> condition disappears. >>=20 >> yes, I would prefer this ;-) >>=20 >>> Do these notes capture the problem space correctly? Or did I miss >> something important? >>>=20 >>> One point that is not clear to me is the timeframe for bringing >> constituent links of a LAG up. I would expect that the requirements > for >> that could be much more relaxed (e.g., in order to avoid link > flapping). >> Is that correct? If it is, one possible implication is that it is > possible >> to use different mechanisms for bringing links DOWN and UP. To the > best >> of my understanding, this is how BFD is supposed to be used with > routing >> adjacencies today, i.e. BFD can bring the adjacency DOWN quite fast, > but >> it has to be brought UP by the appropriate routing protocol. >>=20 >> the draft allows this, section 3.2 "To avoid this deadlock ...". So > using >> BFD to bring down fast alone is covered. Now RFC5882, e.g. section > 4.1, >> mentions that waiting for BFD's Up notification may be useful. Thus = we >> allowed this in the draft as well. >>=20 >>=20 >> [I skip the LACP, CFM part. We had this. Nothing wrong technically = but >> somehow customers push BFD teams to deliver] >=20 > Generally speaking, when up/down use different methods, I've seen a > system fall into continuous flap cycle. Down by BFD, up by = protocol/LMM > is one possible approach, and your draft wants to allow this for > interoperability purpose. I can understand the need, but side effect = can > be nasty, and it (possible continuous flap) can be described? >=20 >=20 > Section 4, first bullet. >=20 > LAG will be taken down when BFD fails on sufficient members (LAG > interface state will be down). LAG will come up potentially when BFD = on > sufficient members come up (LAG interface state will be up). This > behavior implies that all applications will benefit (by monitoring LAG > interface state) even if those applications do not configure BFD on = LAG. > Sure, one can configure applications with BFD over LAG, but that's not > an absolute requirement for this model. Statements regarding this > behavior will be beneficial to readers. >=20 > Thanx, > Nobo >=20 -- Marc Binderberger From manav.bhatia@alcatel-lucent.com Mon Dec 19 02:30:14 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 AE7F421F8B66 for ; Mon, 19 Dec 2011 02:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFEKfSfg8XlX for ; Mon, 19 Dec 2011 02:30:14 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD0C21F8B25 for ; Mon, 19 Dec 2011 02:30:14 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBJAUAI4023587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Dec 2011 04:30:13 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBJAUANS019226 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Dec 2011 16:00:10 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Mon, 19 Dec 2011 16:00:10 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Mon, 19 Dec 2011 16:00:10 +0530 Subject: BFDoLAGs Updated Thread-Topic: BFDoLAGs Updated Thread-Index: Acy+OS9qxsaIYupkSrqnyorVoAJcZQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 10:30:14 -0000 Hi WG members, We have posted a revised version of the BFD over LAGs draft. Its available here: http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt Diff beween the -00 and the -01 version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-01.txt Would be great if the WG members can review this version and provide feedba= ck. We have also included a small discussion on Unicast vs Multicast encapsulat= ion. https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 Cheers, Manav= From Alexander.Vainshtein@ecitele.com Mon Dec 19 04:20:45 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 D209721F8B63 for ; Mon, 19 Dec 2011 04:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=1.511, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21eAGdD8lk-X for ; Mon, 19 Dec 2011 04:20:44 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id E8D3F21F8B52 for ; Mon, 19 Dec 2011 04:20:43 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-182.messagelabs.com!1324297238!7840954!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 16328 invoked from network); 19 Dec 2011 12:20:40 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-182.messagelabs.com with SMTP; 19 Dec 2011 12:20:40 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-97-4eef2d226b8d Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id F0.B7.08306.22D2FEE4; Mon, 19 Dec 2011 14:25:06 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 19 Dec 2011 14:20:39 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" Date: Mon, 19 Dec 2011 14:20:37 +0200 Subject: RE: BFDoLAGs Updated Thread-Topic: BFDoLAGs Updated Thread-Index: Acy+OS9qxsaIYupkSrqnyorVoAJcZQACedxg Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa0zTUBjN7R6WR7UMcZchWouKiCNMJc7IfP5BiShqjDFRLN1la9i6uRZl xsSFaAxIFPEVJ4loEPGJAvFtVGKCEhMw/NDI5AcORVQkPlDiEFuqiLG/zr3nnO98t/k+XKUL aA04x4vIwzMOWhuuPtTz6YuRNn7MSh3oMpgrOjo05s+ha2AxlrHn9V1NRlXVALYa2+gD6QzP u0RGRJQVCayFXu3htjGsl6Y4q4U20ZTbwbDIiXjRQjNuN+Kt9MJw6r8vXZJxPIV41mXleJuF Xr52ldFsTptvNNELpyeY5iwIX2fnBAoZnQznoJxIEBgboqSbLQ0qu6+1Hrj3xBVeqS5S+0B3 TAnAcUjOhZ0+UALCJDgBtnbUaktAOK4jbwIY6rs6RjkcBrB/oE0tq7SkBdZdeKmV8XgJv6m/ NXyvIpNg0aPPY2SsJqfBtqbLGhlHk/Hw+mCNRtFPgicrSn57Z8Pmd6eGMUFmw6ZQ13AXOnIT bP9egck4jNwM7x8NDnuB1N235ouYkqWHL4InMaVrElbdaVEpOAa+ffXztz4GBvbWAkU/C1be /qRVcDKsPvVOpeRGwcfHg2rFGwsf1DxXlwG9f1SEf5TdP8ruH2WvBOrzIJZzuMVcpy11ttFV IKYglhORA6WwLmcdUOak+wZof5LUCEgc0JFEpb83S6dhtgleZyOIxTE6hohL/JilG5vrsnrt jGDP8RQ4kNAIIK6ixxPfuz9k6Qgr492BPK4/lFn60wdVhgjWJU0kL+bMSU3950DriX3s+5U6 0iYNXj5CbuT5Y52I4zQk+pOkxCgPsqHCPM4h/qUxPExOjpSSDydLGkJwM06Bsyl8M5hi0BOn ZYKUCXsBP+KVl2LX0NBQD9BL74wmqmRVpLQyI+4eqTAmFd6f/V4uLC3FCGXwASxyhSd9Q/DE 5K2X7h3ypzSM6y1t2fl0TfHXeaa+ULww6cz9qVs6d+fbqAMP42MzyntDz0sfbn9qTPyRM3nc 4MH1mUlH2Lz+iNvZu9xdiw4sS3tRunnVWJu2bG+mt6al2O7UEc8yi8sTygYM6Ut7A3eOJQTO fU3pmxGcu2BJ4Gw5DttotWBnTDNVHoH5BTX3j+vvAwAA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 12:20:45 -0000 Manav, and all, I've looked up the -01 version of the draft. It seems to address some of my= earlier concerns (mainly dealing with various possible encapsulations) but,= IMHO, still leaves the critical architectural issues unresolved. Please consider the following scenario: A LAG comprises N potential member links but limits the number of concurrent= ly active links to M < N. Priorities of the links are exchanged via LACP (which also guarantees that a= ll the potential links have been, indeed, associated with the same LAG by bo= th peers. The standard behavior in this case would include the following elements: 1. LACP synchronizes priorities locally set for each link (so that each peer= considers the candidate links in exactly the same order) 2. M < N links with highest priorities are bi-directionally agreed upon as b= oth collecting and distributing using LAG. 3. The remaining (M-N) healthy links are still monitored by LACP but do not= carry client traffic, and LACP advertises them as neither" collecting "nor= "distributing". How is this going to change with the introduction of BLM? In particular: 1. Would micro-BFD sessions run on inactive LAG members? 2. Suppose that one of the high priority links goes down, and the micro-BFD= session indicates that two inactive links are healthy - would the link with= the highest priority be selected for activation? 3. Once the new link has been selected, what state would LACP advertise for= it? (My understanding is that activation of a link starts with declaring it= as "collecting but not distributing", and it passes to "collecting and dist= ributing" only after seeing that the partner state is "collecting", but I a= m not sure that the 802.1AX standard dictates this.) 4. Would the LAG try to send user traffic on a link with a healthy micro-BFD= session even if the peer is still advertising its state (via LACP) as "not= collecting"? And what would happen to the traffic received from such a lin= k? In a different scenario, suppose that one of the links has been misconfigure= d with LAG ID that differs from that of the links on the other side. 1. What is supposed to happen to its micro-BFD session (would it be started,= could it reach UP state etc.) 2. Would the LAG try to send traffic via such a link if its micro-BFD sessio= n is UP? The answer is not clear to me because the draft simply states that "BFD take= s precedence over LACP in deciding the fate of individual member links when= both are run in parallel". This can be interpreted in many ways. Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Bhatia, Manav (Manav) > Sent: Monday, December 19, 2011 12:30 PM > To: rtg-bfd@ietf.org > Subject: BFDoLAGs Updated > > Hi WG members, > > We have posted a revised version of the BFD over LAGs draft. > > Its available here: > http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt > > Diff beween the -00 and the -01 version: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-01.txt > > Would be great if the WG members can review this version and provide > feedback. > > We have also included a small discussion on Unicast vs Multicast > encapsulation. > https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 > > Cheers, Manav This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From nobo@cisco.com Mon Dec 19 14:56:59 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 4C7B311E80B0 for ; Mon, 19 Dec 2011 14:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en1kIMcx2hRH for ; Mon, 19 Dec 2011 14:56:58 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 71E7A11E80A0 for ; Mon, 19 Dec 2011 14:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=5819; q=dns/txt; s=iport; t=1324335418; x=1325545018; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eJZ+iJ1Tdk9SpAwDHSorao/7JJvdL2Lpj5D5tH+R47A=; b=TkXLAjGMSzqdaQdbYjrG9URwJHyCeYXPOi1vrCocfJYL2TfeSt8qLde/ 8bSyMhCcJV+tFFWyc0GyGSZPaMn0HQ+LDgQoZqt+TnHdmzyRsWdmtoBdR oeiK/PrufAs6MFXiKQmSydbjv4Dh1XxOzvaRtpjuYbzQADWYj/4SHQaJK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0AAJq/706rRDoJ/2dsb2JhbABDmxqQUIEFgXIBAQEEEgEdCj8MBAIBCBEEAQEBCgYXAQYBRQkIAQEEEwgaoR8BnkuLKWMEiDafFw X-IronPort-AV: E=Sophos;i="4.71,379,1320624000"; d="scan'208";a="19860781" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 19 Dec 2011 22:56:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBJMuwlE012110; Mon, 19 Dec 2011 22:56:58 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Dec 2011 14:56:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: BFD on LAG interfaces Date: Mon, 19 Dec 2011 14:56:54 -0800 Message-ID: In-Reply-To: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: Acy+KMmMadJ1EbjoQ6qoo4dYGxFFOwAdNk3g References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> From: "Nobo Akiya (nobo)" To: "Marc Binderberger" X-OriginalArrivalTime: 19 Dec 2011 22:56:57.0872 (UTC) FILETIME=[82B39100:01CCBEA1] Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 22:56:59 -0000 Hello Marc. I see new revision out there, will have to go check it out. The other question that I have on this draft is, do we really need/want to reserve IP multicast address for this purpose. Most cases, if not all, where operator wants to use BFD to protect LAG at member level should have some sort of IP address assigned at LAG. If not, it can be assigned one (I see no reason where that isn't possible). In such case, could we not use assigned IP address on the LAG to run BFD session at member? Resulting behavior will be less deviating from RFC5881: same demux procedures can be used when discriminator is zero(0), no need to come up with special case of TTL=3D1 which was discussed. I'm = questioning this aspect since I didn't see any strong arguments for burning up IP multicast address. Thanx, Nobo > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, December 19, 2011 5:33 PM > To: Nobo Akiya (nobo) > Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org > Subject: Re: BFD on LAG interfaces >=20 > Hello Nobo, >=20 > thanks for the comments. Let me check this with the new version we are > just preparing (almost done). >=20 > And yes, a cleaner description when the creation/deletion is part of it. > But I also think this is where Alexander's comment came from: without > some modifications in 802.1AX it will not be possible to lock the "going > UP" with BFD. Otherwise you always run into questions and issues - starting > LACP first? Or BFD first? Or both in parallel? >=20 >=20 > > Generally speaking, when up/down use different methods, I've seen a > > system fall into continuous flap cycle. Down by BFD, up by protocol/LMM > > is one possible approach, and your draft wants to allow this for > > interoperability purpose. I can understand the need, but side effect > can > > be nasty, and it (possible continuous flap) can be described? >=20 >=20 > *sigh* yes ... maybe we should write a draft on flap dampening? :-) >=20 >=20 > Let me go through our latest (internal) version if that addresses your > points. >=20 >=20 > Thanks! >=20 > REgards, Marc >=20 >=20 >=20 >=20 > On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: >=20 > > Hello, > > > > Section 3.2. > > > >> A member link of the LAG is not used anymore for data forwarding > > when > >> the particular BFD session running over that link goes down. The > >> member link MUST be removed from the LAG. The BFD session for the > >> link remains, i.e. it is not deleted. > > > > It is not clear when BFD session should get deleted (nor created). With > > above statement, BFD session could remain even when operator decides > to > > shut down a member, depending on how it's interpreted/implemented. When > > LACP is used, LMM will startup LACP only when interface is up. L2 check > > starts only when L1 check passes. Check is done from bottom layer > > upwards. Going by same idea, BFD session should only be created when > L2 > > check passes (LACP), when L2 check is being used. If L2 check is not > > being used, then L1 check is required for BFD session to get created. > > Absence in L1/L2 check pass should cause corresponding BFD sessions > to > > get deleted. > > > > > >>> 3. The situation when LAG goes down due to insufficient number of > > active > >> links must be reversible, i.e., the LAG must be able to go UP once > > this > >> condition disappears. > >> > >> yes, I would prefer this ;-) > >> > >>> Do these notes capture the problem space correctly? Or did I miss > >> something important? > >>> > >>> One point that is not clear to me is the timeframe for bringing > >> constituent links of a LAG up. I would expect that the requirements > > for > >> that could be much more relaxed (e.g., in order to avoid link > > flapping). > >> Is that correct? If it is, one possible implication is that it is > > possible > >> to use different mechanisms for bringing links DOWN and UP. To the > > best > >> of my understanding, this is how BFD is supposed to be used with > > routing > >> adjacencies today, i.e. BFD can bring the adjacency DOWN quite fast, > > but > >> it has to be brought UP by the appropriate routing protocol. > >> > >> the draft allows this, section 3.2 "To avoid this deadlock ...". So > > using > >> BFD to bring down fast alone is covered. Now RFC5882, e.g. section > > 4.1, > >> mentions that waiting for BFD's Up notification may be useful. Thus > we > >> allowed this in the draft as well. > >> > >> > >> [I skip the LACP, CFM part. We had this. Nothing wrong technically > but > >> somehow customers push BFD teams to deliver] > > > > Generally speaking, when up/down use different methods, I've seen a > > system fall into continuous flap cycle. Down by BFD, up by protocol/LMM > > is one possible approach, and your draft wants to allow this for > > interoperability purpose. I can understand the need, but side effect > can > > be nasty, and it (possible continuous flap) can be described? > > > > > > Section 4, first bullet. > > > > LAG will be taken down when BFD fails on sufficient members (LAG > > interface state will be down). LAG will come up potentially when BFD > on > > sufficient members come up (LAG interface state will be up). This > > behavior implies that all applications will benefit (by monitoring LAG > > interface state) even if those applications do not configure BFD on > LAG. > > Sure, one can configure applications with BFD over LAG, but that's not > > an absolute requirement for this model. Statements regarding this > > behavior will be beneficial to readers. > > > > Thanx, > > Nobo > > >=20 > -- > Marc Binderberger From marc@sniff.de Mon Dec 19 15:38: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 F161911E80B1 for ; Mon, 19 Dec 2011 15:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvOIIUxdx7NL for ; Mon, 19 Dec 2011 15:38:33 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6D711E80B0 for ; Mon, 19 Dec 2011 15:38:32 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 06F692AA0F; Mon, 19 Dec 2011 23:38:29 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Tue, 20 Dec 2011 00:38:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> To: Nobo Akiya (nobo) X-Mailer: Apple Mail (2.1084) Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:38:34 -0000 Hello Nobo, > I see new revision out there, will have to go check it out. Thanks for the interest :-) > The other question that I have on this draft is, do we really = need/want > to reserve IP multicast address for this purpose. Most cases, if not > all, where operator wants to use BFD to protect LAG at member level > should have some sort of IP address assigned at LAG. I have seen there had been some "unnumbered" discussion but actually = that is not the reason. Actually "unnumbered" was put aside when we = discussed the original draft-chen-bfd-interface and the list feedback = was to focus on LAG with IP at that time. What we want to achieve: - you can have a member-link session (aka "micro session")=20 - you can have additionally a BBP session (the single session over LAG) = for the main LAG interface On the receiving side, what do you do to differentiate these sessions = (think about the your_discr zero case)? (i) different address (ii) different UDP port Both should work. We started the draft with (i) in mind and I don't see = a hard reason to change this. For (i) you then come up with the idea of a "dedicated address". 127/8 = was proposed by Gregory and again, that would work although ... how do = you differentiate this from a BFD-LSP (RFFC5884) packet arriving on the = LAG interface? So a Multicast address seems another option. > Resulting behavior will be less deviating from RFC5881: same > demux procedures can be used when discriminator is zero(0), so can it for the link-local multihop address I think - no? Now we do = mention this in section 3.2, as a reminder that for your_Discr zero the = main difference is the ingress interface: The demultiplexing of a received packet is solely based on the Your Discriminator field, if this field is nonzero. For the initial Down packet of a micro session this value may be zero. In this case demultiplexing MUST be based on some combination of other fields which MUST include the interface information of the member link. > no need to > come up with special case of TTL=3D1 which was discussed. oh-oh I missed this part! Have to go through the emails. TTL =3D 1 ?!? = Our draft is not talking about this (section 3 mentions RFC5880, so you = would have a TTL of 255) > I'm questioning > this aspect since I didn't see any strong arguments for burning up IP > multicast address. actually I wonder if all-router or all-hosts wouldn't do the job. We = could probably even use 255.255.255.255 as the setup is a direct link, = back to back. Open to this. But if it turns out we need one, well then = we need one. Or alternatively - see (ii) above - a new IANA UDP port. = Not sure what is better/worse. Regards, Marc >=20 > Thanx, > Nobo >=20 >> -----Original Message----- >> From: Marc Binderberger [mailto:marc@sniff.de] >> Sent: Monday, December 19, 2011 5:33 PM >> To: Nobo Akiya (nobo) >> Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org >> Subject: Re: BFD on LAG interfaces >>=20 >> Hello Nobo, >>=20 >> thanks for the comments. Let me check this with the new version we = are >> just preparing (almost done). >>=20 >> And yes, a cleaner description when the creation/deletion is part of > it. >> But I also think this is where Alexander's comment came from: without >> some modifications in 802.1AX it will not be possible to lock the > "going >> UP" with BFD. Otherwise you always run into questions and issues - > starting >> LACP first? Or BFD first? Or both in parallel? >>=20 >>=20 >>> Generally speaking, when up/down use different methods, I've seen a >>> system fall into continuous flap cycle. Down by BFD, up by > protocol/LMM >>> is one possible approach, and your draft wants to allow this for >>> interoperability purpose. I can understand the need, but side effect >> can >>> be nasty, and it (possible continuous flap) can be described? >>=20 >>=20 >> *sigh* yes ... maybe we should write a draft on flap dampening? :-) >>=20 >>=20 >> Let me go through our latest (internal) version if that addresses = your >> points. >>=20 >>=20 >> Thanks! >>=20 >> REgards, Marc >>=20 >>=20 >>=20 >>=20 >> On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: >>=20 >>> Hello, >>>=20 >>> Section 3.2. >>>=20 >>>> A member link of the LAG is not used anymore for data forwarding >>> when >>>> the particular BFD session running over that link goes down. The >>>> member link MUST be removed from the LAG. The BFD session for the >>>> link remains, i.e. it is not deleted. >>>=20 >>> It is not clear when BFD session should get deleted (nor created). > With >>> above statement, BFD session could remain even when operator decides >> to >>> shut down a member, depending on how it's interpreted/implemented. > When >>> LACP is used, LMM will startup LACP only when interface is up. L2 > check >>> starts only when L1 check passes. Check is done from bottom layer >>> upwards. Going by same idea, BFD session should only be created when >> L2 >>> check passes (LACP), when L2 check is being used. If L2 check is not >>> being used, then L1 check is required for BFD session to get > created. >>> Absence in L1/L2 check pass should cause corresponding BFD sessions >> to >>> get deleted. >>>=20 >>>=20 >>>>> 3. The situation when LAG goes down due to insufficient number of >>> active >>>> links must be reversible, i.e., the LAG must be able to go UP once >>> this >>>> condition disappears. >>>>=20 >>>> yes, I would prefer this ;-) >>>>=20 >>>>> Do these notes capture the problem space correctly? Or did I miss >>>> something important? >>>>>=20 >>>>> One point that is not clear to me is the timeframe for bringing >>>> constituent links of a LAG up. I would expect that the requirements >>> for >>>> that could be much more relaxed (e.g., in order to avoid link >>> flapping). >>>> Is that correct? If it is, one possible implication is that it is >>> possible >>>> to use different mechanisms for bringing links DOWN and UP. To the >>> best >>>> of my understanding, this is how BFD is supposed to be used with >>> routing >>>> adjacencies today, i.e. BFD can bring the adjacency DOWN quite > fast, >>> but >>>> it has to be brought UP by the appropriate routing protocol. >>>>=20 >>>> the draft allows this, section 3.2 "To avoid this deadlock ...". So >>> using >>>> BFD to bring down fast alone is covered. Now RFC5882, e.g. section >>> 4.1, >>>> mentions that waiting for BFD's Up notification may be useful. Thus >> we >>>> allowed this in the draft as well. >>>>=20 >>>>=20 >>>> [I skip the LACP, CFM part. We had this. Nothing wrong technically >> but >>>> somehow customers push BFD teams to deliver] >>>=20 >>> Generally speaking, when up/down use different methods, I've seen a >>> system fall into continuous flap cycle. Down by BFD, up by > protocol/LMM >>> is one possible approach, and your draft wants to allow this for >>> interoperability purpose. I can understand the need, but side effect >> can >>> be nasty, and it (possible continuous flap) can be described? >>>=20 >>>=20 >>> Section 4, first bullet. >>>=20 >>> LAG will be taken down when BFD fails on sufficient members (LAG >>> interface state will be down). LAG will come up potentially when BFD >> on >>> sufficient members come up (LAG interface state will be up). This >>> behavior implies that all applications will benefit (by monitoring > LAG >>> interface state) even if those applications do not configure BFD on >> LAG. >>> Sure, one can configure applications with BFD over LAG, but that's > not >>> an absolute requirement for this model. Statements regarding this >>> behavior will be beneficial to readers. >>>=20 >>> Thanx, >>> Nobo >>>=20 >>=20 >> -- >> Marc Binderberger >=20 -- Marc Binderberger From glen.kent@gmail.com Mon Dec 19 16:54: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 7490021F8514 for ; Mon, 19 Dec 2011 16:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROV4wsB4nGNG for ; Mon, 19 Dec 2011 16:54:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3A121F8511 for ; Mon, 19 Dec 2011 16:54:48 -0800 (PST) Received: by iaen33 with SMTP id n33so975432iae.31 for ; Mon, 19 Dec 2011 16:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A1o1RTGSRU80o+yQUeUhJZKeJHrTtlM+EXuRx3SlTGs=; b=TM3iXXcLzGIuUFWe+roMDCD51pOmyjjGjTeKmCB1qX4IgBVCawkONdYH+l3Cz/vULg Ng85kT7/BJZYAUkexNVSzBzSfagTXgeiGvp/INtabSNI1vHl52sRPiKdCu51QmPbNK1Z uBtsKhBTSBNqF2vgELQ8t8qbEd7AulUNW6AwU= MIME-Version: 1.0 Received: by 10.50.181.228 with SMTP id dz4mr29664007igc.22.1324342488123; Mon, 19 Dec 2011 16:54:48 -0800 (PST) Received: by 10.42.174.198 with HTTP; Mon, 19 Dec 2011 16:54:47 -0800 (PST) In-Reply-To: References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> Date: Tue, 20 Dec 2011 06:24:47 +0530 Message-ID: Subject: Re: BFD on LAG interfaces From: Glen Kent To: Marc Binderberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 00:54:49 -0000 Some more reasons for going in for multicast given at the end of the new version. http://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 I dont think there is a need to specify that the TTL=3D1 since the multicast addresses have a link local scope. Am i missing something? Thanks, Glen On Tue, Dec 20, 2011 at 5:08 AM, Marc Binderberger wrote: > Hello Nobo, > >> I see new revision out there, will have to go check it out. > > Thanks for the interest :-) > > >> The other question that I have on this draft is, do we really need/want >> to reserve IP multicast address for this purpose. Most cases, if not >> all, where operator wants to use BFD to protect LAG at member level >> should have some sort of IP address assigned at LAG. > > I have seen there had been some "unnumbered" discussion but actually that= is not the reason. Actually "unnumbered" was put aside when we discussed t= he original draft-chen-bfd-interface and the list feedback was to focus on = LAG with IP at that time. > > > What we want to achieve: > > - you can have a member-link session (aka "micro session") > - you can have additionally a BBP session (the single session over LAG) f= or the main LAG interface > > On the receiving side, what do you do to differentiate these sessions (th= ink about the your_discr zero case)? > > (i) different address > (ii) different UDP port > > > Both should work. We started the draft with (i) in mind and I don't see a= hard reason to change this. > > For (i) you then come up with the idea of a "dedicated address". 127/8 wa= s proposed by Gregory and again, that would work although ... how do you di= fferentiate this from a BFD-LSP (RFFC5884) packet arriving on the LAG inter= face? =A0So a Multicast address seems another option. > > >> Resulting behavior will be less deviating from RFC5881: same >> demux procedures can be used when discriminator is zero(0), > > so can it for the link-local multihop address I think - no? Now we do men= tion this in section 3.2, as a reminder that for your_Discr zero the main d= ifference is the ingress interface: > > =A0 The demultiplexing of a received packet is solely based on the Your > =A0 Discriminator field, if this field is nonzero. =A0For the initial Dow= n > =A0 packet of a micro session this value may be zero. =A0In this case > =A0 demultiplexing MUST be based on some combination of other fields > =A0 which MUST include the interface information of the member link. > > >> no need to >> come up with special case of TTL=3D1 which was discussed. > > > oh-oh I missed this part! Have to go through the emails. TTL =3D 1 ?!? = =A0Our draft is not talking about this (section 3 mentions RFC5880, so you = would have a TTL of 255) > > >> I'm questioning >> this aspect since I didn't see any strong arguments for burning up IP >> multicast address. > > actually I wonder if all-router or all-hosts wouldn't do the job. We coul= d probably even use 255.255.255.255 as the setup is a direct link, back to = back. Open to this. But if it turns out we need one, well then we need one.= Or alternatively - see (ii) above - a new IANA UDP port. Not sure what is = better/worse. > > > Regards, Marc > > > > >> >> Thanx, >> Nobo >> >>> -----Original Message----- >>> From: Marc Binderberger [mailto:marc@sniff.de] >>> Sent: Monday, December 19, 2011 5:33 PM >>> To: Nobo Akiya (nobo) >>> Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org >>> Subject: Re: BFD on LAG interfaces >>> >>> Hello Nobo, >>> >>> thanks for the comments. Let me check this with the new version we are >>> just preparing (almost done). >>> >>> And yes, a cleaner description when the creation/deletion is part of >> it. >>> But I also think this is where Alexander's comment came from: without >>> some modifications in 802.1AX it will not be possible to lock the >> "going >>> UP" with BFD. Otherwise you always run into questions and issues - >> starting >>> LACP first? Or BFD first? Or both in parallel? >>> >>> >>>> Generally speaking, when up/down use different methods, I've seen a >>>> system fall into continuous flap cycle. Down by BFD, up by >> protocol/LMM >>>> is one possible approach, and your draft wants to allow this for >>>> interoperability purpose. I can understand the need, but side effect >>> can >>>> be nasty, and it (possible continuous flap) can be described? >>> >>> >>> *sigh* yes ... maybe we should write a draft on flap dampening? :-) >>> >>> >>> Let me go through our latest (internal) version if that addresses your >>> points. >>> >>> >>> Thanks! >>> >>> REgards, Marc >>> >>> >>> >>> >>> On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: >>> >>>> Hello, >>>> >>>> Section 3.2. >>>> >>>>> A member link of the LAG is not used anymore for data forwarding >>>> when >>>>> the particular BFD session running over that link goes down. =A0The >>>>> member link MUST be removed from the LAG. =A0The BFD session for the >>>>> link remains, i.e. it is not deleted. >>>> >>>> It is not clear when BFD session should get deleted (nor created). >> With >>>> above statement, BFD session could remain even when operator decides >>> to >>>> shut down a member, depending on how it's interpreted/implemented. >> When >>>> LACP is used, LMM will startup LACP only when interface is up. L2 >> check >>>> starts only when L1 check passes. Check is done from bottom layer >>>> upwards. Going by same idea, BFD session should only be created when >>> L2 >>>> check passes (LACP), when L2 check is being used. If L2 check is not >>>> being used, then L1 check is required for BFD session to get >> created. >>>> Absence in L1/L2 check pass should cause corresponding BFD sessions >>> to >>>> get deleted. >>>> >>>> >>>>>> 3. The situation when LAG goes down due to insufficient number of >>>> active >>>>> links must be reversible, i.e., the LAG must be able to go UP once >>>> this >>>>> condition disappears. >>>>> >>>>> yes, I would prefer this ;-) >>>>> >>>>>> Do these notes capture the problem space correctly? Or did I miss >>>>> something important? >>>>>> >>>>>> One point that is not clear to me is the timeframe for bringing >>>>> constituent links of a LAG up. I would expect that the requirements >>>> for >>>>> that could be much more relaxed (e.g., in order to avoid link >>>> flapping). >>>>> Is that correct? If it is, one possible implication is that it is >>>> possible >>>>> to use different mechanisms for bringing links DOWN and UP. To the >>>> best >>>>> of my understanding, this is how BFD is supposed to be used with >>>> routing >>>>> adjacencies today, i.e. BFD can bring the adjacency DOWN quite >> fast, >>>> but >>>>> it has to be brought UP by the appropriate routing protocol. >>>>> >>>>> the draft allows this, section 3.2 "To avoid this deadlock ...". So >>>> using >>>>> BFD to bring down fast alone is covered. Now RFC5882, e.g. section >>>> 4.1, >>>>> mentions that waiting for BFD's Up notification may be useful. Thus >>> we >>>>> allowed this in the draft as well. >>>>> >>>>> >>>>> [I skip the LACP, CFM part. We had this. Nothing wrong technically >>> but >>>>> somehow customers push BFD teams to deliver] >>>> >>>> Generally speaking, when up/down use different methods, I've seen a >>>> system fall into continuous flap cycle. Down by BFD, up by >> protocol/LMM >>>> is one possible approach, and your draft wants to allow this for >>>> interoperability purpose. I can understand the need, but side effect >>> can >>>> be nasty, and it (possible continuous flap) can be described? >>>> >>>> >>>> Section 4, first bullet. >>>> >>>> LAG will be taken down when BFD fails on sufficient members (LAG >>>> interface state will be down). LAG will come up potentially when BFD >>> on >>>> sufficient members come up (LAG interface state will be up). This >>>> behavior implies that all applications will benefit (by monitoring >> LAG >>>> interface state) even if those applications do not configure BFD on >>> LAG. >>>> Sure, one can configure applications with BFD over LAG, but that's >> not >>>> an absolute requirement for this model. Statements regarding this >>>> behavior will be beneficial to readers. >>>> >>>> Thanx, >>>> Nobo >>>> >>> >>> -- >>> Marc Binderberger =A0 =A0 =A0 =A0 =A0 >> > > -- > Marc Binderberger =A0 =A0 =A0 =A0 =A0 > From nobo@cisco.com Mon Dec 19 18:30:14 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 CB23C11E8094 for ; Mon, 19 Dec 2011 18:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TEh2PPDjH7K for ; Mon, 19 Dec 2011 18:30:13 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A1DB511E8080 for ; Mon, 19 Dec 2011 18:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=11916; q=dns/txt; s=iport; t=1324348213; x=1325557813; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=d2DoIGTdf8E6Cpn4qJIOxw6N1zqkCxV7Osog7sdlwsU=; b=UZ4a3AjllkK+3PgHHV1HSAgzqkL0dGxvSlblIVqDBpBbletFWjLXtyAZ Lz34Mwque1pFSVsUrkqx5cEvqRLjbuOnKpEz03W+nFo69S6dqdcsTxwIZ Wc82svS5w9wzV81bQPZ6JkbQ/Gt5iFkZAqX/O7eu8fY4mHgHdhOrPBxdA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0AALfx706rRDoI/2dsb2JhbABDmxuQUIEFgXIBAQEDARIBHUkFBwQCAQgRBAEBAQoGFwEGASAlCQgBAQQBEggah1gImRIBnlyLKWMEiAMzlzaHYQ X-IronPort-AV: E=Sophos;i="4.71,379,1320624000"; d="scan'208";a="21584626" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 20 Dec 2011 02:30:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBK2UDes027692; Tue, 20 Dec 2011 02:30:13 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Dec 2011 18:30:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: EuNM IRED LUcH L3/m QB/G QqbI SZFi SgrA ZOyD a5Z1 flQv hI9N ie/4 oeog qsSu thC1; 4; ZABrAGEAdAB6AEAAagB1AG4AaQBwAGUAcgAuAG4AZQB0ADsAZwBsAGUAbgAuAGsAZQBuAHQAQABnAG0AYQBpAGwALgBjAG8AbQA7AG0AYQByAGMAQABzAG4AaQBmAGYALgBkAGUAOwByAHQAZwAtAGIAZgBkAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {510D9F74-5738-4444-AF78-4BACBEF2CFE7}; bgBvAGIAbwBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Tue, 20 Dec 2011 02:30:00 GMT; UgBFADoAIABCAEYARAAgAG8AbgAgAEwAQQBHACAAaQBuAHQAZQByAGYAYQBjAGUAcwA= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {510D9F74-5738-4444-AF78-4BACBEF2CFE7} Content-class: urn:content-classes:message Subject: RE: BFD on LAG interfaces Date: Mon, 19 Dec 2011 18:29:59 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: Acy+sfons4MoVogZT4Kw+HeXFIIzIwAAkS5g References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> From: "Nobo Akiya (nobo)" To: "Glen Kent" , "Marc Binderberger" X-OriginalArrivalTime: 20 Dec 2011 02:30:13.0161 (UTC) FILETIME=[4D49B990:01CCBEBF] Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 02:30:14 -0000 Hello Marc, Glen, Thanx for prompt response. > I dont think there is a need to specify that the TTL=3D1 since the > multicast addresses have a link local scope. Am i missing something? Somewhere in the thread, "TTL for all IPv4 multicast packets MUST be 1" = was mentioned by Manav. Nice appendix in the new revision. Some comments. (1) Unicast ARP disadvantage becomes moot if you add third option of = using well-known multicast/broadcast MAC. (2) Unicast configuration difficulty is valid in a sense that one would = need to configure destination IP address. (3) Unnumbered IP address, I'm a bit slow on this one. Can you elaborate = a bit more on this issue? > >> Resulting behavior will be less deviating from RFC5881: same > >> demux procedures can be used when discriminator is zero(0), > > > > so can it for the link-local multihop address I think - no? Now we = do > mention this in section 3.2, as a reminder that for your_Discr zero = the > main difference is the ingress interface: For regular RFC5881 sessions, incoming packets with zero(0) = discriminator is usually demux'ed mainly based on incoming interface and = source IP address. I was pointing out that implementation will most = likely need to stem off to slightly deviating demux code, if destination = IP of received packets is a multicast address. o Minimal code changes to support micro BFD sessions per member link. A new UDP port number can be used to differentiate BFD control packets associated with the micro BFD sessions and the regular BFD sessions. Running regular BFD sessions on top of bundle which has micro BFD = sessions per member enabled make sense if they are of deviating AF or if = regular sessions are on subinterface. But running on same AF on main = bundle ... yeah it actually make sense. Primary strength here is that = regular session is able run echo, which micro BFD sessions per member = isn't able to do, allowing much better coverage. You are right, if we = went to unicast destination IP address, UDP port is only thing we have = to differentiate the sessions, which usage of multicast destination IP = would appear simpler. Second sentence of above snippet is really more of = advantage of multicast destination IP approach, IMO. Also related, should the draft make suggestion of running per member = only on bundle main interface, or allowing same mechanism to be used = even on bundle subinterface? Thanx, Nobo > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com] > Sent: Tuesday, December 20, 2011 9:55 AM > To: Marc Binderberger > Cc: Nobo Akiya (nobo); rtg-bfd@ietf.org; Dave Katz > Subject: Re: BFD on LAG interfaces >=20 > Some more reasons for going in for multicast given at the end of the > new version. >=20 > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >=20 > I dont think there is a need to specify that the TTL=3D1 since the > multicast addresses have a link local scope. Am i missing something? >=20 > Thanks, > Glen >=20 > On Tue, Dec 20, 2011 at 5:08 AM, Marc Binderberger = wrote: > > Hello Nobo, > > > >> I see new revision out there, will have to go check it out. > > > > Thanks for the interest :-) > > > > > >> The other question that I have on this draft is, do we really = need/want > >> to reserve IP multicast address for this purpose. Most cases, if = not > >> all, where operator wants to use BFD to protect LAG at member level > >> should have some sort of IP address assigned at LAG. > > > > I have seen there had been some "unnumbered" discussion but actually > that is not the reason. Actually "unnumbered" was put aside when we > discussed the original draft-chen-bfd-interface and the list feedback > was to focus on LAG with IP at that time. > > > > > > What we want to achieve: > > > > - you can have a member-link session (aka "micro session") > > - you can have additionally a BBP session (the single session over = LAG) > for the main LAG interface > > > > On the receiving side, what do you do to differentiate these = sessions > (think about the your_discr zero case)? > > > > (i) different address > > (ii) different UDP port > > > > > > Both should work. We started the draft with (i) in mind and I don't > see a hard reason to change this. > > > > For (i) you then come up with the idea of a "dedicated address". = 127/8 > was proposed by Gregory and again, that would work although ... how do > you differentiate this from a BFD-LSP (RFFC5884) packet arriving on = the > LAG interface? =A0So a Multicast address seems another option. > > > > > >> Resulting behavior will be less deviating from RFC5881: same > >> demux procedures can be used when discriminator is zero(0), > > > > so can it for the link-local multihop address I think - no? Now we = do > mention this in section 3.2, as a reminder that for your_Discr zero = the > main difference is the ingress interface: > > > > =A0 The demultiplexing of a received packet is solely based on the = Your > > =A0 Discriminator field, if this field is nonzero. =A0For the = initial Down > > =A0 packet of a micro session this value may be zero. =A0In this = case > > =A0 demultiplexing MUST be based on some combination of other fields > > =A0 which MUST include the interface information of the member link. > > > > > >> no need to > >> come up with special case of TTL=3D1 which was discussed. > > > > > > oh-oh I missed this part! Have to go through the emails. TTL =3D 1 = ?!? =A0Our > draft is not talking about this (section 3 mentions RFC5880, so you = would > have a TTL of 255) > > > > > >> I'm questioning > >> this aspect since I didn't see any strong arguments for burning up > IP > >> multicast address. > > > > actually I wonder if all-router or all-hosts wouldn't do the job. We > could probably even use 255.255.255.255 as the setup is a direct link, > back to back. Open to this. But if it turns out we need one, well then > we need one. Or alternatively - see (ii) above - a new IANA UDP port. > Not sure what is better/worse. > > > > > > Regards, Marc > > > > > > > > > >> > >> Thanx, > >> Nobo > >> > >>> -----Original Message----- > >>> From: Marc Binderberger [mailto:marc@sniff.de] > >>> Sent: Monday, December 19, 2011 5:33 PM > >>> To: Nobo Akiya (nobo) > >>> Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org > >>> Subject: Re: BFD on LAG interfaces > >>> > >>> Hello Nobo, > >>> > >>> thanks for the comments. Let me check this with the new version we > are > >>> just preparing (almost done). > >>> > >>> And yes, a cleaner description when the creation/deletion is part > of > >> it. > >>> But I also think this is where Alexander's comment came from: = without > >>> some modifications in 802.1AX it will not be possible to lock the > >> "going > >>> UP" with BFD. Otherwise you always run into questions and issues - > >> starting > >>> LACP first? Or BFD first? Or both in parallel? > >>> > >>> > >>>> Generally speaking, when up/down use different methods, I've seen > a > >>>> system fall into continuous flap cycle. Down by BFD, up by > >> protocol/LMM > >>>> is one possible approach, and your draft wants to allow this for > >>>> interoperability purpose. I can understand the need, but side = effect > >>> can > >>>> be nasty, and it (possible continuous flap) can be described? > >>> > >>> > >>> *sigh* yes ... maybe we should write a draft on flap dampening? = :-) > >>> > >>> > >>> Let me go through our latest (internal) version if that addresses > your > >>> points. > >>> > >>> > >>> Thanks! > >>> > >>> REgards, Marc > >>> > >>> > >>> > >>> > >>> On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: > >>> > >>>> Hello, > >>>> > >>>> Section 3.2. > >>>> > >>>>> A member link of the LAG is not used anymore for data forwarding > >>>> when > >>>>> the particular BFD session running over that link goes down. = =A0The > >>>>> member link MUST be removed from the LAG. =A0The BFD session for = the > >>>>> link remains, i.e. it is not deleted. > >>>> > >>>> It is not clear when BFD session should get deleted (nor = created). > >> With > >>>> above statement, BFD session could remain even when operator = decides > >>> to > >>>> shut down a member, depending on how it's = interpreted/implemented. > >> When > >>>> LACP is used, LMM will startup LACP only when interface is up. L2 > >> check > >>>> starts only when L1 check passes. Check is done from bottom layer > >>>> upwards. Going by same idea, BFD session should only be created = when > >>> L2 > >>>> check passes (LACP), when L2 check is being used. If L2 check is > not > >>>> being used, then L1 check is required for BFD session to get > >> created. > >>>> Absence in L1/L2 check pass should cause corresponding BFD = sessions > >>> to > >>>> get deleted. > >>>> > >>>> > >>>>>> 3. The situation when LAG goes down due to insufficient number > of > >>>> active > >>>>> links must be reversible, i.e., the LAG must be able to go UP = once > >>>> this > >>>>> condition disappears. > >>>>> > >>>>> yes, I would prefer this ;-) > >>>>> > >>>>>> Do these notes capture the problem space correctly? Or did I = miss > >>>>> something important? > >>>>>> > >>>>>> One point that is not clear to me is the timeframe for bringing > >>>>> constituent links of a LAG up. I would expect that the = requirements > >>>> for > >>>>> that could be much more relaxed (e.g., in order to avoid link > >>>> flapping). > >>>>> Is that correct? If it is, one possible implication is that it = is > >>>> possible > >>>>> to use different mechanisms for bringing links DOWN and UP. To = the > >>>> best > >>>>> of my understanding, this is how BFD is supposed to be used with > >>>> routing > >>>>> adjacencies today, i.e. BFD can bring the adjacency DOWN quite > >> fast, > >>>> but > >>>>> it has to be brought UP by the appropriate routing protocol. > >>>>> > >>>>> the draft allows this, section 3.2 "To avoid this deadlock ...". > So > >>>> using > >>>>> BFD to bring down fast alone is covered. Now RFC5882, e.g. = section > >>>> 4.1, > >>>>> mentions that waiting for BFD's Up notification may be useful. = Thus > >>> we > >>>>> allowed this in the draft as well. > >>>>> > >>>>> > >>>>> [I skip the LACP, CFM part. We had this. Nothing wrong = technically > >>> but > >>>>> somehow customers push BFD teams to deliver] > >>>> > >>>> Generally speaking, when up/down use different methods, I've seen > a > >>>> system fall into continuous flap cycle. Down by BFD, up by > >> protocol/LMM > >>>> is one possible approach, and your draft wants to allow this for > >>>> interoperability purpose. I can understand the need, but side = effect > >>> can > >>>> be nasty, and it (possible continuous flap) can be described? > >>>> > >>>> > >>>> Section 4, first bullet. > >>>> > >>>> LAG will be taken down when BFD fails on sufficient members (LAG > >>>> interface state will be down). LAG will come up potentially when > BFD > >>> on > >>>> sufficient members come up (LAG interface state will be up). This > >>>> behavior implies that all applications will benefit (by = monitoring > >> LAG > >>>> interface state) even if those applications do not configure BFD > on > >>> LAG. > >>>> Sure, one can configure applications with BFD over LAG, but = that's > >> not > >>>> an absolute requirement for this model. Statements regarding this > >>>> behavior will be beneficial to readers. > >>>> > >>>> Thanx, > >>>> Nobo > >>>> > >>> > >>> -- > >>> Marc Binderberger =A0 =A0 =A0 =A0 =A0 > >> > > > > -- > > Marc Binderberger =A0 =A0 =A0 =A0 =A0 > > From glen.kent@gmail.com Mon Dec 19 19:22:42 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 31FA321F84A4 for ; Mon, 19 Dec 2011 19:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Noy1A-Bzn6Dc for ; Mon, 19 Dec 2011 19:22:41 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5821F84A2 for ; Mon, 19 Dec 2011 19:22:41 -0800 (PST) Received: by iaen33 with SMTP id n33so1159704iae.31 for ; Mon, 19 Dec 2011 19:22:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uuAOcElKmG5eSwuFahYrpFnWl+F3UkUnZPxilvSvEg0=; b=KvyjV0Mi44WaV8QBsGsPGHbghsB5m2n0A6hJU1xiXOQWN4HkltZ0w1gjuthdSr585c KzJFrR0+lSGxOJPgximbYcFVTATTfSecTmnWofeosIXhDjL2l+KgHiat51LFM1kGiNpo q1uW3IrlMssrrj7eOyXV5ZeUFgJ3t0GDva2i4= MIME-Version: 1.0 Received: by 10.50.155.195 with SMTP id vy3mr531461igb.46.1324351359459; Mon, 19 Dec 2011 19:22:39 -0800 (PST) Received: by 10.42.174.198 with HTTP; Mon, 19 Dec 2011 19:22:39 -0800 (PST) In-Reply-To: References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> Date: Tue, 20 Dec 2011 08:52:39 +0530 Message-ID: Subject: Re: BFD on LAG interfaces From: Glen Kent To: "Nobo Akiya (nobo)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 03:22:42 -0000 Hi Nobo, > Also related, should the draft make suggestion of running per member > only on bundle main interface, or allowing same mechanism to be used even= on bundle subinterface? subinterfaces afaik is a Cisco specific implement. Are you talking about IP interfaces with different vlans on the same phy port? Thanks, Glen > > Thanx, > Nobo > >> -----Original Message----- >> From: Glen Kent [mailto:glen.kent@gmail.com] >> Sent: Tuesday, December 20, 2011 9:55 AM >> To: Marc Binderberger >> Cc: Nobo Akiya (nobo); rtg-bfd@ietf.org; Dave Katz >> Subject: Re: BFD on LAG interfaces >> >> Some more reasons for going in for multicast given at the end of the >> new version. >> >> http://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >> >> I dont think there is a need to specify that the TTL=3D1 since the >> multicast addresses have a link local scope. Am i missing something? >> >> Thanks, >> Glen >> >> On Tue, Dec 20, 2011 at 5:08 AM, Marc Binderberger wrote= : >> > Hello Nobo, >> > >> >> I see new revision out there, will have to go check it out. >> > >> > Thanks for the interest :-) >> > >> > >> >> The other question that I have on this draft is, do we really need/wa= nt >> >> to reserve IP multicast address for this purpose. Most cases, if not >> >> all, where operator wants to use BFD to protect LAG at member level >> >> should have some sort of IP address assigned at LAG. >> > >> > I have seen there had been some "unnumbered" discussion but actually >> that is not the reason. Actually "unnumbered" was put aside when we >> discussed the original draft-chen-bfd-interface and the list feedback >> was to focus on LAG with IP at that time. >> > >> > >> > What we want to achieve: >> > >> > - you can have a member-link session (aka "micro session") >> > - you can have additionally a BBP session (the single session over LAG= ) >> for the main LAG interface >> > >> > On the receiving side, what do you do to differentiate these sessions >> (think about the your_discr zero case)? >> > >> > (i) different address >> > (ii) different UDP port >> > >> > >> > Both should work. We started the draft with (i) in mind and I don't >> see a hard reason to change this. >> > >> > For (i) you then come up with the idea of a "dedicated address". 127/8 >> was proposed by Gregory and again, that would work although ... how do >> you differentiate this from a BFD-LSP (RFFC5884) packet arriving on the >> LAG interface? =A0So a Multicast address seems another option. >> > >> > >> >> Resulting behavior will be less deviating from RFC5881: same >> >> demux procedures can be used when discriminator is zero(0), >> > >> > so can it for the link-local multihop address I think - no? Now we do >> mention this in section 3.2, as a reminder that for your_Discr zero the >> main difference is the ingress interface: >> > >> > =A0 The demultiplexing of a received packet is solely based on the You= r >> > =A0 Discriminator field, if this field is nonzero. =A0For the initial = Down >> > =A0 packet of a micro session this value may be zero. =A0In this case >> > =A0 demultiplexing MUST be based on some combination of other fields >> > =A0 which MUST include the interface information of the member link. >> > >> > >> >> no need to >> >> come up with special case of TTL=3D1 which was discussed. >> > >> > >> > oh-oh I missed this part! Have to go through the emails. TTL =3D 1 ?!?= =A0Our >> draft is not talking about this (section 3 mentions RFC5880, so you woul= d >> have a TTL of 255) >> > >> > >> >> I'm questioning >> >> this aspect since I didn't see any strong arguments for burning up >> IP >> >> multicast address. >> > >> > actually I wonder if all-router or all-hosts wouldn't do the job. We >> could probably even use 255.255.255.255 as the setup is a direct link, >> back to back. Open to this. But if it turns out we need one, well then >> we need one. Or alternatively - see (ii) above - a new IANA UDP port. >> Not sure what is better/worse. >> > >> > >> > Regards, Marc >> > >> > >> > >> > >> >> >> >> Thanx, >> >> Nobo >> >> >> >>> -----Original Message----- >> >>> From: Marc Binderberger [mailto:marc@sniff.de] >> >>> Sent: Monday, December 19, 2011 5:33 PM >> >>> To: Nobo Akiya (nobo) >> >>> Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org >> >>> Subject: Re: BFD on LAG interfaces >> >>> >> >>> Hello Nobo, >> >>> >> >>> thanks for the comments. Let me check this with the new version we >> are >> >>> just preparing (almost done). >> >>> >> >>> And yes, a cleaner description when the creation/deletion is part >> of >> >> it. >> >>> But I also think this is where Alexander's comment came from: withou= t >> >>> some modifications in 802.1AX it will not be possible to lock the >> >> "going >> >>> UP" with BFD. Otherwise you always run into questions and issues - >> >> starting >> >>> LACP first? Or BFD first? Or both in parallel? >> >>> >> >>> >> >>>> Generally speaking, when up/down use different methods, I've seen >> a >> >>>> system fall into continuous flap cycle. Down by BFD, up by >> >> protocol/LMM >> >>>> is one possible approach, and your draft wants to allow this for >> >>>> interoperability purpose. I can understand the need, but side effec= t >> >>> can >> >>>> be nasty, and it (possible continuous flap) can be described? >> >>> >> >>> >> >>> *sigh* yes ... maybe we should write a draft on flap dampening? :-) >> >>> >> >>> >> >>> Let me go through our latest (internal) version if that addresses >> your >> >>> points. >> >>> >> >>> >> >>> Thanks! >> >>> >> >>> REgards, Marc >> >>> >> >>> >> >>> >> >>> >> >>> On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: >> >>> >> >>>> Hello, >> >>>> >> >>>> Section 3.2. >> >>>> >> >>>>> A member link of the LAG is not used anymore for data forwarding >> >>>> when >> >>>>> the particular BFD session running over that link goes down. =A0Th= e >> >>>>> member link MUST be removed from the LAG. =A0The BFD session for t= he >> >>>>> link remains, i.e. it is not deleted. >> >>>> >> >>>> It is not clear when BFD session should get deleted (nor created). >> >> With >> >>>> above statement, BFD session could remain even when operator decide= s >> >>> to >> >>>> shut down a member, depending on how it's interpreted/implemented. >> >> When >> >>>> LACP is used, LMM will startup LACP only when interface is up. L2 >> >> check >> >>>> starts only when L1 check passes. Check is done from bottom layer >> >>>> upwards. Going by same idea, BFD session should only be created whe= n >> >>> L2 >> >>>> check passes (LACP), when L2 check is being used. If L2 check is >> not >> >>>> being used, then L1 check is required for BFD session to get >> >> created. >> >>>> Absence in L1/L2 check pass should cause corresponding BFD sessions >> >>> to >> >>>> get deleted. >> >>>> >> >>>> >> >>>>>> 3. The situation when LAG goes down due to insufficient number >> of >> >>>> active >> >>>>> links must be reversible, i.e., the LAG must be able to go UP once >> >>>> this >> >>>>> condition disappears. >> >>>>> >> >>>>> yes, I would prefer this ;-) >> >>>>> >> >>>>>> Do these notes capture the problem space correctly? Or did I miss >> >>>>> something important? >> >>>>>> >> >>>>>> One point that is not clear to me is the timeframe for bringing >> >>>>> constituent links of a LAG up. I would expect that the requirement= s >> >>>> for >> >>>>> that could be much more relaxed (e.g., in order to avoid link >> >>>> flapping). >> >>>>> Is that correct? If it is, one possible implication is that it is >> >>>> possible >> >>>>> to use different mechanisms for bringing links DOWN and UP. To the >> >>>> best >> >>>>> of my understanding, this is how BFD is supposed to be used with >> >>>> routing >> >>>>> adjacencies today, i.e. BFD can bring the adjacency DOWN quite >> >> fast, >> >>>> but >> >>>>> it has to be brought UP by the appropriate routing protocol. >> >>>>> >> >>>>> the draft allows this, section 3.2 "To avoid this deadlock ...". >> So >> >>>> using >> >>>>> BFD to bring down fast alone is covered. Now RFC5882, e.g. section >> >>>> 4.1, >> >>>>> mentions that waiting for BFD's Up notification may be useful. Thu= s >> >>> we >> >>>>> allowed this in the draft as well. >> >>>>> >> >>>>> >> >>>>> [I skip the LACP, CFM part. We had this. Nothing wrong technically >> >>> but >> >>>>> somehow customers push BFD teams to deliver] >> >>>> >> >>>> Generally speaking, when up/down use different methods, I've seen >> a >> >>>> system fall into continuous flap cycle. Down by BFD, up by >> >> protocol/LMM >> >>>> is one possible approach, and your draft wants to allow this for >> >>>> interoperability purpose. I can understand the need, but side effec= t >> >>> can >> >>>> be nasty, and it (possible continuous flap) can be described? >> >>>> >> >>>> >> >>>> Section 4, first bullet. >> >>>> >> >>>> LAG will be taken down when BFD fails on sufficient members (LAG >> >>>> interface state will be down). LAG will come up potentially when >> BFD >> >>> on >> >>>> sufficient members come up (LAG interface state will be up). This >> >>>> behavior implies that all applications will benefit (by monitoring >> >> LAG >> >>>> interface state) even if those applications do not configure BFD >> on >> >>> LAG. >> >>>> Sure, one can configure applications with BFD over LAG, but that's >> >> not >> >>>> an absolute requirement for this model. Statements regarding this >> >>>> behavior will be beneficial to readers. >> >>>> >> >>>> Thanx, >> >>>> Nobo >> >>>> >> >>> >> >>> -- >> >>> Marc Binderberger =A0 =A0 =A0 =A0 =A0 >> >> >> > >> > -- >> > Marc Binderberger =A0 =A0 =A0 =A0 =A0 >> > From nobo@cisco.com Mon Dec 19 21:30:21 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 661D711E80C6 for ; Mon, 19 Dec 2011 21:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q75xRY0xwe3i for ; Mon, 19 Dec 2011 21:30:20 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 39F7D11E80B4 for ; Mon, 19 Dec 2011 21:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=11112; q=dns/txt; s=iport; t=1324359020; x=1325568620; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=cFh8Fm1tT9zWf8Fyb9seQisbLquDv3SenkvnE/X4P0c=; b=TZ8vZWIH5ctMqcGwTB6+z15EtVVVcPBzWfJcbpyUfZkBYsEI2MQm6IDT 1+N4+yhfqLJ1FnxA/wL74g2VKo/M++OgxjX/EAyWUm0vUW8bLyGmfDLaV lBudKsc0RF5qXJkPELJ/KUcRGFNr7Etqxj8WYFU7a1Sh344a5jGLBEA7n I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYAAGQc8E6rRDoG/2dsb2JhbABDmyGQT4EFgXIBAQEDARIBHUkMBAIBCBEEAQEBCgYXAQYBICUJCAEBBBMIGodYCJhuAZ5MiyljBIgEM5c3h2I X-IronPort-AV: E=Sophos;i="4.71,380,1320624000"; d="scan'208";a="19906376" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 20 Dec 2011 05:30:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBK5UIbb031072; Tue, 20 Dec 2011 05:30:18 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Dec 2011 21:30:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BFD on LAG interfaces Date: Mon, 19 Dec 2011 21:30:16 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: Acy+xqLMkEQs8osxTtaxgOHM27QluAAEUO3g References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> From: "Nobo Akiya (nobo)" To: "Glen Kent" X-OriginalArrivalTime: 20 Dec 2011 05:30:18.0540 (UTC) FILETIME=[75CBB6C0:01CCBED8] Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 05:30:21 -0000 Hello Glen, > -----Original Message----- > From: Glen Kent [mailto:glen.kent@gmail.com] > Sent: Tuesday, December 20, 2011 12:23 PM > To: Nobo Akiya (nobo) > Cc: Marc Binderberger; rtg-bfd@ietf.org; Dave Katz > Subject: Re: BFD on LAG interfaces >=20 > Hi Nobo, >=20 > > Also related, should the draft make suggestion of running per member > > only on bundle main interface, or allowing same mechanism to be used > even on bundle subinterface? >=20 > subinterfaces afaik is a Cisco specific implement. Are you talking > about IP interfaces with different vlans on the same phy port? Sorry for not using right terminology there. I meant 801.1q on an ether = bundle (ex: bundle-ether1.1). Thanx, Nobo >=20 > Thanks, > Glen >=20 > > > > Thanx, > > Nobo > > > >> -----Original Message----- > >> From: Glen Kent [mailto:glen.kent@gmail.com] > >> Sent: Tuesday, December 20, 2011 9:55 AM > >> To: Marc Binderberger > >> Cc: Nobo Akiya (nobo); rtg-bfd@ietf.org; Dave Katz > >> Subject: Re: BFD on LAG interfaces > >> > >> Some more reasons for going in for multicast given at the end of = the > >> new version. > >> > >> http://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 > >> > >> I dont think there is a need to specify that the TTL=3D1 since the > >> multicast addresses have a link local scope. Am i missing = something? > >> > >> Thanks, > >> Glen > >> > >> On Tue, Dec 20, 2011 at 5:08 AM, Marc Binderberger > wrote: > >> > Hello Nobo, > >> > > >> >> I see new revision out there, will have to go check it out. > >> > > >> > Thanks for the interest :-) > >> > > >> > > >> >> The other question that I have on this draft is, do we really > need/want > >> >> to reserve IP multicast address for this purpose. Most cases, if > not > >> >> all, where operator wants to use BFD to protect LAG at member = level > >> >> should have some sort of IP address assigned at LAG. > >> > > >> > I have seen there had been some "unnumbered" discussion but = actually > >> that is not the reason. Actually "unnumbered" was put aside when we > >> discussed the original draft-chen-bfd-interface and the list = feedback > >> was to focus on LAG with IP at that time. > >> > > >> > > >> > What we want to achieve: > >> > > >> > - you can have a member-link session (aka "micro session") > >> > - you can have additionally a BBP session (the single session = over > LAG) > >> for the main LAG interface > >> > > >> > On the receiving side, what do you do to differentiate these = sessions > >> (think about the your_discr zero case)? > >> > > >> > (i) different address > >> > (ii) different UDP port > >> > > >> > > >> > Both should work. We started the draft with (i) in mind and I = don't > >> see a hard reason to change this. > >> > > >> > For (i) you then come up with the idea of a "dedicated address". > 127/8 > >> was proposed by Gregory and again, that would work although ... how > do > >> you differentiate this from a BFD-LSP (RFFC5884) packet arriving on > the > >> LAG interface? =A0So a Multicast address seems another option. > >> > > >> > > >> >> Resulting behavior will be less deviating from RFC5881: same > >> >> demux procedures can be used when discriminator is zero(0), > >> > > >> > so can it for the link-local multihop address I think - no? Now = we > do > >> mention this in section 3.2, as a reminder that for your_Discr zero > the > >> main difference is the ingress interface: > >> > > >> > =A0 The demultiplexing of a received packet is solely based on = the > Your > >> > =A0 Discriminator field, if this field is nonzero. =A0For the = initial > Down > >> > =A0 packet of a micro session this value may be zero. =A0In this = case > >> > =A0 demultiplexing MUST be based on some combination of other = fields > >> > =A0 which MUST include the interface information of the member = link. > >> > > >> > > >> >> no need to > >> >> come up with special case of TTL=3D1 which was discussed. > >> > > >> > > >> > oh-oh I missed this part! Have to go through the emails. TTL =3D > 1 ?!? =A0Our > >> draft is not talking about this (section 3 mentions RFC5880, so you > would > >> have a TTL of 255) > >> > > >> > > >> >> I'm questioning > >> >> this aspect since I didn't see any strong arguments for burning > up > >> IP > >> >> multicast address. > >> > > >> > actually I wonder if all-router or all-hosts wouldn't do the job. > We > >> could probably even use 255.255.255.255 as the setup is a direct = link, > >> back to back. Open to this. But if it turns out we need one, well = then > >> we need one. Or alternatively - see (ii) above - a new IANA UDP = port. > >> Not sure what is better/worse. > >> > > >> > > >> > Regards, Marc > >> > > >> > > >> > > >> > > >> >> > >> >> Thanx, > >> >> Nobo > >> >> > >> >>> -----Original Message----- > >> >>> From: Marc Binderberger [mailto:marc@sniff.de] > >> >>> Sent: Monday, December 19, 2011 5:33 PM > >> >>> To: Nobo Akiya (nobo) > >> >>> Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org > >> >>> Subject: Re: BFD on LAG interfaces > >> >>> > >> >>> Hello Nobo, > >> >>> > >> >>> thanks for the comments. Let me check this with the new version > we > >> are > >> >>> just preparing (almost done). > >> >>> > >> >>> And yes, a cleaner description when the creation/deletion is = part > >> of > >> >> it. > >> >>> But I also think this is where Alexander's comment came from: > without > >> >>> some modifications in 802.1AX it will not be possible to lock = the > >> >> "going > >> >>> UP" with BFD. Otherwise you always run into questions and = issues > - > >> >> starting > >> >>> LACP first? Or BFD first? Or both in parallel? > >> >>> > >> >>> > >> >>>> Generally speaking, when up/down use different methods, I've = seen > >> a > >> >>>> system fall into continuous flap cycle. Down by BFD, up by > >> >> protocol/LMM > >> >>>> is one possible approach, and your draft wants to allow this = for > >> >>>> interoperability purpose. I can understand the need, but side > effect > >> >>> can > >> >>>> be nasty, and it (possible continuous flap) can be described? > >> >>> > >> >>> > >> >>> *sigh* yes ... maybe we should write a draft on flap dampening? = :-) > >> >>> > >> >>> > >> >>> Let me go through our latest (internal) version if that = addresses > >> your > >> >>> points. > >> >>> > >> >>> > >> >>> Thanks! > >> >>> > >> >>> REgards, Marc > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: > >> >>> > >> >>>> Hello, > >> >>>> > >> >>>> Section 3.2. > >> >>>> > >> >>>>> A member link of the LAG is not used anymore for data = forwarding > >> >>>> when > >> >>>>> the particular BFD session running over that link goes down. = =A0The > >> >>>>> member link MUST be removed from the LAG. =A0The BFD session = for > the > >> >>>>> link remains, i.e. it is not deleted. > >> >>>> > >> >>>> It is not clear when BFD session should get deleted (nor = created). > >> >> With > >> >>>> above statement, BFD session could remain even when operator > decides > >> >>> to > >> >>>> shut down a member, depending on how it's = interpreted/implemented. > >> >> When > >> >>>> LACP is used, LMM will startup LACP only when interface is up. > L2 > >> >> check > >> >>>> starts only when L1 check passes. Check is done from bottom = layer > >> >>>> upwards. Going by same idea, BFD session should only be = created > when > >> >>> L2 > >> >>>> check passes (LACP), when L2 check is being used. If L2 check > is > >> not > >> >>>> being used, then L1 check is required for BFD session to get > >> >> created. > >> >>>> Absence in L1/L2 check pass should cause corresponding BFD > sessions > >> >>> to > >> >>>> get deleted. > >> >>>> > >> >>>> > >> >>>>>> 3. The situation when LAG goes down due to insufficient = number > >> of > >> >>>> active > >> >>>>> links must be reversible, i.e., the LAG must be able to go UP > once > >> >>>> this > >> >>>>> condition disappears. > >> >>>>> > >> >>>>> yes, I would prefer this ;-) > >> >>>>> > >> >>>>>> Do these notes capture the problem space correctly? Or did I > miss > >> >>>>> something important? > >> >>>>>> > >> >>>>>> One point that is not clear to me is the timeframe for = bringing > >> >>>>> constituent links of a LAG up. I would expect that the > requirements > >> >>>> for > >> >>>>> that could be much more relaxed (e.g., in order to avoid link > >> >>>> flapping). > >> >>>>> Is that correct? If it is, one possible implication is that = it > is > >> >>>> possible > >> >>>>> to use different mechanisms for bringing links DOWN and UP. = To > the > >> >>>> best > >> >>>>> of my understanding, this is how BFD is supposed to be used = with > >> >>>> routing > >> >>>>> adjacencies today, i.e. BFD can bring the adjacency DOWN = quite > >> >> fast, > >> >>>> but > >> >>>>> it has to be brought UP by the appropriate routing protocol. > >> >>>>> > >> >>>>> the draft allows this, section 3.2 "To avoid this deadlock = ...". > >> So > >> >>>> using > >> >>>>> BFD to bring down fast alone is covered. Now RFC5882, e.g. = section > >> >>>> 4.1, > >> >>>>> mentions that waiting for BFD's Up notification may be = useful. > Thus > >> >>> we > >> >>>>> allowed this in the draft as well. > >> >>>>> > >> >>>>> > >> >>>>> [I skip the LACP, CFM part. We had this. Nothing wrong = technically > >> >>> but > >> >>>>> somehow customers push BFD teams to deliver] > >> >>>> > >> >>>> Generally speaking, when up/down use different methods, I've = seen > >> a > >> >>>> system fall into continuous flap cycle. Down by BFD, up by > >> >> protocol/LMM > >> >>>> is one possible approach, and your draft wants to allow this = for > >> >>>> interoperability purpose. I can understand the need, but side > effect > >> >>> can > >> >>>> be nasty, and it (possible continuous flap) can be described? > >> >>>> > >> >>>> > >> >>>> Section 4, first bullet. > >> >>>> > >> >>>> LAG will be taken down when BFD fails on sufficient members = (LAG > >> >>>> interface state will be down). LAG will come up potentially = when > >> BFD > >> >>> on > >> >>>> sufficient members come up (LAG interface state will be up). = This > >> >>>> behavior implies that all applications will benefit (by = monitoring > >> >> LAG > >> >>>> interface state) even if those applications do not configure = BFD > >> on > >> >>> LAG. > >> >>>> Sure, one can configure applications with BFD over LAG, but = that's > >> >> not > >> >>>> an absolute requirement for this model. Statements regarding = this > >> >>>> behavior will be beneficial to readers. > >> >>>> > >> >>>> Thanx, > >> >>>> Nobo > >> >>>> > >> >>> > >> >>> -- > >> >>> Marc Binderberger =A0 =A0 =A0 =A0 =A0 > >> >> > >> > > >> > -- > >> > Marc Binderberger =A0 =A0 =A0 =A0 =A0 > >> > From toms.sanders@gmail.com Tue Dec 20 18:02:44 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 83FCF11E8089 for ; Tue, 20 Dec 2011 18:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyffVxmXfZo3 for ; Tue, 20 Dec 2011 18:02:44 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id D29FB11E8073 for ; Tue, 20 Dec 2011 18:02:43 -0800 (PST) Received: by wibhj6 with SMTP id hj6so2079006wib.31 for ; Tue, 20 Dec 2011 18:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8dEQG5Kck7Y1Ss8eRz9hxdIB9uRlI585tTOqaKwpaRA=; b=qefNLHNKddNNIkLOCEHBBxzCyXrvbXyz2p7KZ7iPD03YmBK7K3UNVMAStQbUsRMRqd obM0JuRpGxIx4TnYOuWxaJY6c4HyapEIEiH+5Y0Bggtk9On5nOF+ycshDUqeleKTdusG vIx4kFS1CHedTEZY6SMomhXYs5ECwq8/ed504= MIME-Version: 1.0 Received: by 10.180.19.74 with SMTP id c10mr9683920wie.8.1324432962939; Tue, 20 Dec 2011 18:02:42 -0800 (PST) Received: by 10.223.89.12 with HTTP; Tue, 20 Dec 2011 18:02:42 -0800 (PST) In-Reply-To: References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> Date: Wed, 21 Dec 2011 07:32:42 +0530 Message-ID: Subject: Re: BFD on LAG interfaces From: Tom Sanders To: "Nobo Akiya (nobo)" Content-Type: text/plain; charset=UTF-8 Cc: rtg-bfd@ietf.org, Dave Katz 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, 21 Dec 2011 02:02:44 -0000 >> >> subinterfaces afaik is a Cisco specific implement. Are you talking >> about IP interfaces with different vlans on the same phy port? > > Sorry for not using right terminology there. I meant 801.1q on an ether bundle (ex: bundle-ether1.1). > The authors can correct me if i am greatly off the mark, but as per my understanding, we may not need to run micro BFD sessions per dot1q LAG interfaces. Look at each micro BFD session as an entity that interacts with LACP (which runs at a port level) and helps it to monitor & the maintain the LAG. Toms. From nobo@cisco.com Tue Dec 20 18:17:17 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 1212D11E809F for ; Tue, 20 Dec 2011 18:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.922 X-Spam-Level: X-Spam-Status: No, score=-5.922 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0uIRuXFeouJ for ; Tue, 20 Dec 2011 18:17:16 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6C311E809A for ; Tue, 20 Dec 2011 18:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=1734; q=dns/txt; s=iport; t=1324433836; x=1325643436; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=MA5BL2m56z7Uf2z5r9vMxAyFnfDGFAxI2Subco7yWJ4=; b=FcjkjPsPlkrsmQTOVXruQvEJsfIGm1RhafJlbK4ruLZDFhXzPIDvAPdH g1RjQfll7jbIhROoOL+1pzPk38Yn7wWd3YLKoFTYODECErNqR0nPlxjE4 pWh4ZSr6t2AQCwqdKBT5Wj1GDg2Bnkjl3k+XWTDteHiBmC/lB4iUpfXeS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIlA8U6rRDoG/2dsb2JhbABDhQ+lXYElgQWBcgEBAQQSARANBEUQAgEIGgIGBhgCAgIBAVUBAQQbGqBXAYxbkVmBL4lKM2MEiDefGw X-IronPort-AV: E=Sophos;i="4.71,385,1320624000"; d="scan'208";a="20090338" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 21 Dec 2011 02:17:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBL2HGMi023056; Wed, 21 Dec 2011 02:17:16 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 18:17:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: BFD on LAG interfaces Date: Tue, 20 Dec 2011 18:17:14 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: Acy/hKEAzBGGDR+YRmqp5gHJV/velQAAKZ/Q References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> From: "Nobo Akiya (nobo)" To: "Tom Sanders" X-OriginalArrivalTime: 21 Dec 2011 02:17:16.0112 (UTC) FILETIME=[A88B3500:01CCBF86] Cc: rtg-bfd@ietf.org, Dave Katz 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, 21 Dec 2011 02:17:17 -0000 SGVsbG8gVG9tLA0KDQo+ID4+DQo+ID4+IHN1YmludGVyZmFjZXMgYWZhaWsgaXMgYSBDaXNjbyBz cGVjaWZpYyBpbXBsZW1lbnQuIEFyZSB5b3UgdGFsa2luZw0KPiA+PiBhYm91dCBJUCBpbnRlcmZh Y2VzIHdpdGggZGlmZmVyZW50IHZsYW5zIG9uIHRoZSBzYW1lIHBoeSBwb3J0Pw0KPiA+DQo+ID4g U29ycnkgZm9yIG5vdCB1c2luZyByaWdodCB0ZXJtaW5vbG9neSB0aGVyZS4gSSBtZWFudCA4MDEu MXEgb24gYW4gZXRoZXINCj4gYnVuZGxlIChleDogYnVuZGxlLWV0aGVyMS4xKS4NCj4gPg0KPiAN Cj4gVGhlIGF1dGhvcnMgY2FuIGNvcnJlY3QgbWUgaWYgaSBhbSBncmVhdGx5IG9mZiB0aGUgbWFy aywgYnV0IGFzIHBlciBteQ0KPiB1bmRlcnN0YW5kaW5nLCB3ZSBtYXkgbm90IG5lZWQgdG8gcnVu IG1pY3JvIEJGRCBzZXNzaW9ucyBwZXIgZG90MXEgTEFHDQo+IGludGVyZmFjZXMuIExvb2sgYXQg ZWFjaCBtaWNybyBCRkQgc2Vzc2lvbiBhcyBhbiBlbnRpdHkgdGhhdCBpbnRlcmFjdHMNCj4gd2l0 aCBMQUNQICh3aGljaCBydW5zIGF0IGEgcG9ydCBsZXZlbCkgYW5kIGhlbHBzIGl0IHRvIG1vbml0 b3IgJiB0aGUNCj4gbWFpbnRhaW4gdGhlIExBRy4NCj4gDQo+IFRvbXMuDQoNCkFncmVlLiBUaGVv cmV0aWNhbGx5LCBpdCBzaG91bGQgYmUgcG9zc2libGUgZm9yIEJGRCB0byBydW4gbWljcm8gQkZE IHNlc3Npb25zIHBlciA4MDIuMXEsIG5vdCB0aGF0IHdlIHdhbnQgdG8gZnJvbSBzY2FsZSBwZXJz cGVjdGl2ZS4gSG93ZXZlciwgaXQgd291bGQgYmUgZGlmZmljdWx0IGZvciBMTU0gdG8gcmVhY3Qg dG8gZmFpbHVyZXMgYXQgc3VjaCBncmFudWxhcml0eS4gU2FtZSBhcHBsaWVzIHRvIHJ1bm5pbmcg bWljcm8gQkZEIHNlc3Npb25zIGZvciBib3RoIHY0IGFuZCB2NiBhdCBtYWluIDgwMi4xYXguIEFG IGFzcGVjdCBpcyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0IGluIHNlYyAzLjEuDQoNCiAgIFBlciBC TE0gc2Vzc2lvbiByZXF1ZXN0IG9ubHkgb25lIGFkZHJlc3MgZmFtaWx5IGNhbiBiZSB1c2VkLiAg SS5lLg0KICAgdGhlIHNldCBvZiBtaWNybyBzZXNzaW9ucyBiZWxvbmdpbmcgdG8gdGhlIEJMTSBz ZXNzaW9uIE1VU1QgZWl0aGVyDQogICBhbGwgdXNlIElQdjQgb3IgYWxsIHVzZSBJUHY2Lg0KDQpC dXQgc2luY2UgODAyLjFxIGFzcGVjdCB3YXNuJ3Qgc3BlY2lmaWNhbGx5IG1lbnRpb25lZCAoYSBi aXQgaW1wbGllZCBpbiBzZWN0aW9uIDQpLCBJIHdhcyBzaW1wbHkgY3VyaW91cy4NCg0KVGhhbngs DQpOb2JvDQoNCg== From mach.chen@huawei.com Tue Dec 20 18:31:08 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 C5FF411E808A for ; Tue, 20 Dec 2011 18:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDjKicStEKZ2 for ; Tue, 20 Dec 2011 18:31:08 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2231611E8073 for ; Tue, 20 Dec 2011 18:31:08 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWJ00MKR8A4EF@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Wed, 21 Dec 2011 10:30:04 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWJ0020W8A3WN@szxga05-in.huawei.com> for rtg-bfd@ietf.org; Wed, 21 Dec 2011 10:30:04 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFY12363; Wed, 21 Dec 2011 10:29:36 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Dec 2011 10:29:32 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.67]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Wed, 21 Dec 2011 10:29:36 +0800 Date: Wed, 21 Dec 2011 02:29:34 +0000 From: Mach Chen Subject: RE: BFD on LAG interfaces In-reply-to: X-Originating-IP: [10.108.4.61] To: "Nobo Akiya (nobo)" , Tom Sanders Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: BFD on LAG interfaces Thread-index: Acy7JDMdrqbrLGipReylGpRIoRTZpQAAFq0AACsaK4AAd3b+AAANuA6AAB4v5QAAAXOiAAACqlOAAANTKIAAAdbggAAEdPsAACsK0QAAAIHwAAAQ73pw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> Cc: "rtg-bfd@ietf.org" , Dave Katz 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, 21 Dec 2011 02:31:08 -0000 Hi Nobo and Tom, Thanks for your comments. You are right, the draft is intended to run macro BFD session per port. We could update the draft to explicitly mention this to make it clearer in the revision. Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Nobo Akiya (nobo) > Sent: Wednesday, December 21, 2011 10:17 AM > To: Tom Sanders > Cc: rtg-bfd@ietf.org; Dave Katz > Subject: RE: BFD on LAG interfaces > > Hello Tom, > > > >> > > >> subinterfaces afaik is a Cisco specific implement. Are you talking > > >> about IP interfaces with different vlans on the same phy port? > > > > > > Sorry for not using right terminology there. I meant 801.1q on an ether > > bundle (ex: bundle-ether1.1). > > > > > > > The authors can correct me if i am greatly off the mark, but as per my > > understanding, we may not need to run micro BFD sessions per dot1q LAG > > interfaces. Look at each micro BFD session as an entity that interacts > > with LACP (which runs at a port level) and helps it to monitor & the > > maintain the LAG. > > > > Toms. > > Agree. Theoretically, it should be possible for BFD to run micro BFD sessions > per 802.1q, not that we want to from scale perspective. However, it would be > difficult for LMM to react to failures at such granularity. Same applies to > running micro BFD sessions for both v4 and v6 at main 802.1ax. AF aspect is > mentioned in the draft in sec 3.1. > > Per BLM session request only one address family can be used. I.e. > the set of micro sessions belonging to the BLM session MUST either > all use IPv4 or all use IPv6. > > But since 802.1q aspect wasn't specifically mentioned (a bit implied in section > 4), I was simply curious. > > Thanx, > Nobo From manav.bhatia@alcatel-lucent.com Tue Dec 20 20:18:19 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 2CDCD1F0C49 for ; Tue, 20 Dec 2011 20:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10t8hVqlO96I for ; Tue, 20 Dec 2011 20:18:18 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id A76ED1F0C3B for ; Tue, 20 Dec 2011 20:18:18 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBL4ICN3024298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 22:18:14 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBL4IBeX009479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Dec 2011 09:48:11 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 21 Dec 2011 09:48:11 +0530 From: "Bhatia, Manav (Manav)" To: "Nobo Akiya (nobo)" , Tom Sanders Date: Wed, 21 Dec 2011 09:48:09 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy/hKEAzBGGDR+YRmqp5gHJV/velQAAKZ/QAARijsA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D026F1943@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-bfd@ietf.org" , Dave Katz 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, 21 Dec 2011 04:18:19 -0000 Hi Nobo, =20 > Agree. Theoretically, it should be possible for BFD to run=20 > micro BFD sessions per 802.1q, not that we want to from scale=20 > perspective. However, it would be difficult for LMM to react=20 > to failures at such granularity. Same applies to running=20 Yes that's correct. Moreover, we don't NEED to run separate micro sessions = per .1q interface. Running it per port should be fine. If the micro session= goes down then LMM takes care of removing this port from all LAGs that it'= s a part of. > micro BFD sessions for both v4 and v6 at main 802.1ax. AF=20 > aspect is mentioned in the draft in sec 3.1. >=20 > Per BLM session request only one address family can be used. I.e. > the set of micro sessions belonging to the BLM session MUST either > all use IPv4 or all use IPv6. >=20 > But since 802.1q aspect wasn't specifically mentioned (a bit=20 > implied in section 4), I was simply curious. Yup, we should include a note on this. Cheers, Manav >=20 > Thanx, > Nobo >=20 > = From marc@sniff.de Wed Dec 21 03:21:54 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 CBFE121F8531 for ; Wed, 21 Dec 2011 03:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iEkzdUvq-h8 for ; Wed, 21 Dec 2011 03:21:54 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA6021F852E for ; Wed, 21 Dec 2011 03:21:53 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 38EC82AA0F; Wed, 21 Dec 2011 11:21:51 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Wed, 21 Dec 2011 12:21:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <545636D2-10C2-4625-AB53-E974BDDE4805@sniff.de> References: <30607333-A6F8-4317-97BB-1522DDF269E4@sniff.de> To: Tom Sanders , "Nobo Akiya (nobo)" , Dave Katz 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, 21 Dec 2011 11:21:54 -0000 Hello Nobo and Tom, most answers have been given already - and yes, we should be explicit = that we want to send micro sessions untagged, i.e. without a VLAN. > Same applies to running micro BFD sessions for both v4 and v6 at main = 802.1ax. AF aspect is mentioned in the draft in sec 3.1. >=20 > Per BLM session request only one address family can be used. I.e. > the set of micro sessions belonging to the BLM session MUST either > all use IPv4 or all use IPv6. right, but there is still a detail missing as we don't forbid to request = an IPv4 BLM and also an IPv6 BLM for the same LAG. As we work on section = 5 to be more detailed on the 802.1AX part I think we need to mention = which logic to be used: OR-logic, i.e. any BFD Down trigger removes the = link from distributed state? What also needs an update is section 4: here we use the concluded state = of the corresponding BLM session. Bu which one, that of BLM-IPv4 or = BLM-IPv6? :-) We may need to reword this a bit, ala "using the = concluded state of the BLM session for the same LAG and with the same = AF" or such. And of course this discussion depends on the detail if we go with BFD in = IP/UDP encapsulation; only then Address Family makes sense. Dave, I haven't seen a reply regarding my questions. Still have the = problem that "unnatural" and "tap into private API" is a bit vague to be = addressed. Or in other words: where starts "natural" and what API model = are we allowed to use? Regards, Marc On 2011-12-21, at 3:17 , Nobo Akiya (nobo) wrote: > Hello Tom, >=20 >>>>=20 >>>> subinterfaces afaik is a Cisco specific implement. Are you talking >>>> about IP interfaces with different vlans on the same phy port? >>>=20 >>> Sorry for not using right terminology there. I meant 801.1q on an = ether >> bundle (ex: bundle-ether1.1). >>>=20 >>=20 >> The authors can correct me if i am greatly off the mark, but as per = my >> understanding, we may not need to run micro BFD sessions per dot1q = LAG >> interfaces. Look at each micro BFD session as an entity that = interacts >> with LACP (which runs at a port level) and helps it to monitor & the >> maintain the LAG. >>=20 >> Toms. >=20 > Agree. Theoretically, it should be possible for BFD to run micro BFD = sessions per 802.1q, not that we want to from scale perspective. = However, it would be difficult for LMM to react to failures at such = granularity. Same applies to running micro BFD sessions for both v4 and = v6 at main 802.1ax. AF aspect is mentioned in the draft in sec 3.1. >=20 > Per BLM session request only one address family can be used. I.e. > the set of micro sessions belonging to the BLM session MUST either > all use IPv4 or all use IPv6. >=20 > But since 802.1q aspect wasn't specifically mentioned (a bit implied = in section 4), I was simply curious. >=20 > Thanx, > Nobo >=20 -- Marc Binderberger From toms.sanders@gmail.com Wed Dec 21 16:30: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 4A3C011E80C0 for ; Wed, 21 Dec 2011 16:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juWpsv9E2SDW for ; Wed, 21 Dec 2011 16:30:36 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE811E8096 for ; Wed, 21 Dec 2011 16:30:35 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so11453484wgb.13 for ; Wed, 21 Dec 2011 16:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=HgLjF9FX/WqCBE3gSR1FlPqIHVTrF2k3nvD1MhiVY/o=; b=VSSyq4cQTEXhQ4q07jlABGsa4fngAbVbYS941YL5vO7dG5Jd5ZD4clcs/HcmCch1l1 gMwfst3LzbxPSQfhbjJtal8eYrr/UD7ZjPnWRpWMQTh1LdwNRIExTbErpXZV5aiuiJMZ t0esho708RMiFq4mDkMhitZBxmEDrCazXMOOg= MIME-Version: 1.0 Received: by 10.227.207.15 with SMTP id fw15mr8370663wbb.15.1324513835065; Wed, 21 Dec 2011 16:30:35 -0800 (PST) Received: by 10.223.89.12 with HTTP; Wed, 21 Dec 2011 16:30:35 -0800 (PST) Date: Thu, 22 Dec 2011 06:00:35 +0530 Message-ID: Subject: Multicast vs Unicast (was BFD on LAG interfaces) From: Tom Sanders To: rtg-bfd@ietf.org Content-Type: text/plain; charset=UTF-8 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: Thu, 22 Dec 2011 00:30:37 -0000 The two options before the WG are: 1. Use IP encapsulation 2. Use direct L2 encapsulation. With (1) we have an option of (1a) Using Multicast and (1b) Using Unicast. Can we arrive on a consensus between choosing 1a and 1b? Given that the new draft has this nice Appendix that succinctly discusses this, can the proponents of (1b) justify why they think (1a) is not good enough. Lets try closing the different threads so that we can converge towards a solution. Toms On 20 December 2011 06:24, Glen Kent wrote: > Some more reasons for going in for multicast given at the end of the > new version. > > http://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 > > I dont think there is a need to specify that the TTL=3D1 since the > multicast addresses have a link local scope. Am i missing something? > > Thanks, > Glen > > On Tue, Dec 20, 2011 at 5:08 AM, Marc Binderberger wrote: >> Hello Nobo, >> >>> I see new revision out there, will have to go check it out. >> >> Thanks for the interest :-) >> >> >>> The other question that I have on this draft is, do we really need/want >>> to reserve IP multicast address for this purpose. Most cases, if not >>> all, where operator wants to use BFD to protect LAG at member level >>> should have some sort of IP address assigned at LAG. >> >> I have seen there had been some "unnumbered" discussion but actually tha= t is not the reason. Actually "unnumbered" was put aside when we discussed = the original draft-chen-bfd-interface and the list feedback was to focus on= LAG with IP at that time. >> >> >> What we want to achieve: >> >> - you can have a member-link session (aka "micro session") >> - you can have additionally a BBP session (the single session over LAG) = for the main LAG interface >> >> On the receiving side, what do you do to differentiate these sessions (t= hink about the your_discr zero case)? >> >> (i) different address >> (ii) different UDP port >> >> >> Both should work. We started the draft with (i) in mind and I don't see = a hard reason to change this. >> >> For (i) you then come up with the idea of a "dedicated address". 127/8 w= as proposed by Gregory and again, that would work although ... how do you d= ifferentiate this from a BFD-LSP (RFFC5884) packet arriving on the LAG inte= rface? =C2=A0So a Multicast address seems another option. >> >> >>> Resulting behavior will be less deviating from RFC5881: same >>> demux procedures can be used when discriminator is zero(0), >> >> so can it for the link-local multihop address I think - no? Now we do me= ntion this in section 3.2, as a reminder that for your_Discr zero the main = difference is the ingress interface: >> >> =C2=A0 The demultiplexing of a received packet is solely based on the Yo= ur >> =C2=A0 Discriminator field, if this field is nonzero. =C2=A0For the init= ial Down >> =C2=A0 packet of a micro session this value may be zero. =C2=A0In this c= ase >> =C2=A0 demultiplexing MUST be based on some combination of other fields >> =C2=A0 which MUST include the interface information of the member link. >> >> >>> no need to >>> come up with special case of TTL=3D1 which was discussed. >> >> >> oh-oh I missed this part! Have to go through the emails. TTL =3D 1 ?!? = =C2=A0Our draft is not talking about this (section 3 mentions RFC5880, so y= ou would have a TTL of 255) >> >> >>> I'm questioning >>> this aspect since I didn't see any strong arguments for burning up IP >>> multicast address. >> >> actually I wonder if all-router or all-hosts wouldn't do the job. We cou= ld probably even use 255.255.255.255 as the setup is a direct link, back to= back. Open to this. But if it turns out we need one, well then we need one= . Or alternatively - see (ii) above - a new IANA UDP port. Not sure what is= better/worse. >> >> >> Regards, Marc >> >> >> >> >>> >>> Thanx, >>> Nobo >>> >>>> -----Original Message----- >>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>> Sent: Monday, December 19, 2011 5:33 PM >>>> To: Nobo Akiya (nobo) >>>> Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org >>>> Subject: Re: BFD on LAG interfaces >>>> >>>> Hello Nobo, >>>> >>>> thanks for the comments. Let me check this with the new version we are >>>> just preparing (almost done). >>>> >>>> And yes, a cleaner description when the creation/deletion is part of >>> it. >>>> But I also think this is where Alexander's comment came from: without >>>> some modifications in 802.1AX it will not be possible to lock the >>> "going >>>> UP" with BFD. Otherwise you always run into questions and issues - >>> starting >>>> LACP first? Or BFD first? Or both in parallel? >>>> >>>> >>>>> Generally speaking, when up/down use different methods, I've seen a >>>>> system fall into continuous flap cycle. Down by BFD, up by >>> protocol/LMM >>>>> is one possible approach, and your draft wants to allow this for >>>>> interoperability purpose. I can understand the need, but side effect >>>> can >>>>> be nasty, and it (possible continuous flap) can be described? >>>> >>>> >>>> *sigh* yes ... maybe we should write a draft on flap dampening? :-) >>>> >>>> >>>> Let me go through our latest (internal) version if that addresses your >>>> points. >>>> >>>> >>>> Thanks! >>>> >>>> REgards, Marc >>>> >>>> >>>> >>>> >>>> On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: >>>> >>>>> Hello, >>>>> >>>>> Section 3.2. >>>>> >>>>>> A member link of the LAG is not used anymore for data forwarding >>>>> when >>>>>> the particular BFD session running over that link goes down. =C2=A0T= he >>>>>> member link MUST be removed from the LAG. =C2=A0The BFD session for = the >>>>>> link remains, i.e. it is not deleted. >>>>> >>>>> It is not clear when BFD session should get deleted (nor created). >>> With >>>>> above statement, BFD session could remain even when operator decides >>>> to >>>>> shut down a member, depending on how it's interpreted/implemented. >>> When >>>>> LACP is used, LMM will startup LACP only when interface is up. L2 >>> check >>>>> starts only when L1 check passes. Check is done from bottom layer >>>>> upwards. Going by same idea, BFD session should only be created when >>>> L2 >>>>> check passes (LACP), when L2 check is being used. If L2 check is not >>>>> being used, then L1 check is required for BFD session to get >>> created. >>>>> Absence in L1/L2 check pass should cause corresponding BFD sessions >>>> to >>>>> get deleted. >>>>> >>>>> >>>>>>> 3. The situation when LAG goes down due to insufficient number of >>>>> active >>>>>> links must be reversible, i.e., the LAG must be able to go UP once >>>>> this >>>>>> condition disappears. >>>>>> >>>>>> yes, I would prefer this ;-) >>>>>> >>>>>>> Do these notes capture the problem space correctly? Or did I miss >>>>>> something important? >>>>>>> >>>>>>> One point that is not clear to me is the timeframe for bringing >>>>>> constituent links of a LAG up. I would expect that the requirements >>>>> for >>>>>> that could be much more relaxed (e.g., in order to avoid link >>>>> flapping). >>>>>> Is that correct? If it is, one possible implication is that it is >>>>> possible >>>>>> to use different mechanisms for bringing links DOWN and UP. To the >>>>> best >>>>>> of my understanding, this is how BFD is supposed to be used with >>>>> routing >>>>>> adjacencies today, i.e. BFD can bring the adjacency DOWN quite >>> fast, >>>>> but >>>>>> it has to be brought UP by the appropriate routing protocol. >>>>>> >>>>>> the draft allows this, section 3.2 "To avoid this deadlock ...". So >>>>> using >>>>>> BFD to bring down fast alone is covered. Now RFC5882, e.g. section >>>>> 4.1, >>>>>> mentions that waiting for BFD's Up notification may be useful. Thus >>>> we >>>>>> allowed this in the draft as well. >>>>>> >>>>>> >>>>>> [I skip the LACP, CFM part. We had this. Nothing wrong technically >>>> but >>>>>> somehow customers push BFD teams to deliver] >>>>> >>>>> Generally speaking, when up/down use different methods, I've seen a >>>>> system fall into continuous flap cycle. Down by BFD, up by >>> protocol/LMM >>>>> is one possible approach, and your draft wants to allow this for >>>>> interoperability purpose. I can understand the need, but side effect >>>> can >>>>> be nasty, and it (possible continuous flap) can be described? >>>>> >>>>> >>>>> Section 4, first bullet. >>>>> >>>>> LAG will be taken down when BFD fails on sufficient members (LAG >>>>> interface state will be down). LAG will come up potentially when BFD >>>> on >>>>> sufficient members come up (LAG interface state will be up). This >>>>> behavior implies that all applications will benefit (by monitoring >>> LAG >>>>> interface state) even if those applications do not configure BFD on >>>> LAG. >>>>> Sure, one can configure applications with BFD over LAG, but that's >>> not >>>>> an absolute requirement for this model. Statements regarding this >>>>> behavior will be beneficial to readers. >>>>> >>>>> Thanx, >>>>> Nobo >>>>> >>>> >>>> -- >>>> Marc Binderberger =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> >> >> -- >> Marc Binderberger =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >> --=20 Toms. From jeff.tantsura@ericsson.com Wed Dec 21 16:58:20 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 413A821F8AFA for ; Wed, 21 Dec 2011 16:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcN01KmgkvNd for ; Wed, 21 Dec 2011 16:58:19 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1C72B21F8AF1 for ; Wed, 21 Dec 2011 16:58:19 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pBM0wGNx011264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Dec 2011 18:58:16 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 21 Dec 2011 19:58:16 -0500 From: Jeff Tantsura To: Tom Sanders , "rtg-bfd@ietf.org" Date: Wed, 21 Dec 2011 19:58:13 -0500 Subject: RE: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Topic: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Index: AczAQPTu3oPOhK5OQV+7omB+4H1LXgAACrNg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C5694C2@EUSAACMS0701.eamcs.ericsson.se> References: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 00:58:20 -0000 SGksDQoNCi8qY3VzdG9tZXIvcHJvZHVjdCBtYW5hZ2VyIG1vZGUqLw0KSWYgd2Ugc2V0IGFzaWRl IHJlbGlnaW91cyBkaXNjdXNzaW9uIGFib3V0IGxheWVyIHZpb2xhdGlvbi9ldGMgSU1ITyAxYSBp cyBqdXN0IGZpbmUsIGl0IGFsbG93cyByZXVzaW5nIGV4aXN0aW5nIEJGRCBpbXBsZW1lbnRhdGlv bnMgd2l0aCBtaW5pbXVtIGNoYW5nZXMsIGhlbmNlIGRlY3JlYXNlcyB0aW1lIHRvIG1hcmtldCA9 PSBoYXBweSBjdXN0b21lcnMuDQpJIHRoaW5rIHdlIHNob3VsZCBzdGlsbCBiZSBrZWVwaW5nIG91 ciBmb2N1cyBvbiBJUCBMQUcsIGFzIHdlIGFyZSB0cnlpbmcgdG8gZXh0ZW5kIFJGQzU4ODEgdG8g d29yayBvdmVyIExBRyB3aGVyZSBCRkQgaXMgdXNlZCBpcyB0byB0cmFjayBJUHY0IGFuZCBJUHY2 IGNvbm5lY3Rpdml0eSBiZXR3ZWVuIGRpcmVjdGx5IGNvbm5lY3RlZCBzeXN0ZW1zIA0KSU1PIGZv ciBMMiBMQUcgRXRoIE9BTSB3b3VsZCBtYWtlIG11Y2ggbW9yZSBzZW5zZSAoZWcuIC4xYWcgYXdh cmUgTEFHKS4NCg0KUmVnYXJkcywNCkplZmYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRnLWJmZC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVG9tIFNhbmRlcnMNClNlbnQ6IFdlZG5lc2RheSwgRGVj ZW1iZXIgMjEsIDIwMTEgNDozMSBQTQ0KVG86IHJ0Zy1iZmRAaWV0Zi5vcmcNClN1YmplY3Q6IE11 bHRpY2FzdCB2cyBVbmljYXN0ICh3YXMgQkZEIG9uIExBRyBpbnRlcmZhY2VzKQ0KDQpUaGUgdHdv IG9wdGlvbnMgYmVmb3JlIHRoZSBXRyBhcmU6DQoNCjEuIFVzZSBJUCBlbmNhcHN1bGF0aW9uDQoy LiBVc2UgZGlyZWN0IEwyIGVuY2Fwc3VsYXRpb24uDQoNCldpdGggKDEpIHdlIGhhdmUgYW4gb3B0 aW9uIG9mICgxYSkgVXNpbmcgTXVsdGljYXN0IGFuZCAoMWIpIFVzaW5nIFVuaWNhc3QuDQoNCkNh biB3ZSBhcnJpdmUgb24gYSBjb25zZW5zdXMgYmV0d2VlbiBjaG9vc2luZyAxYSBhbmQgMWI/DQoN CkdpdmVuIHRoYXQgdGhlIG5ldyBkcmFmdCBoYXMgdGhpcyBuaWNlIEFwcGVuZGl4IHRoYXQgc3Vj Y2luY3RseSBkaXNjdXNzZXMgdGhpcywgY2FuIHRoZSBwcm9wb25lbnRzIG9mICgxYikganVzdGlm eSB3aHkgdGhleSB0aGluayAoMWEpIGlzIG5vdCBnb29kIGVub3VnaC4NCg0KTGV0cyB0cnkgY2xv c2luZyB0aGUgZGlmZmVyZW50IHRocmVhZHMgc28gdGhhdCB3ZSBjYW4gY29udmVyZ2UgdG93YXJk cyBhIHNvbHV0aW9uLg0KDQpUb21zDQoNCk9uIDIwIERlY2VtYmVyIDIwMTEgMDY6MjQsIEdsZW4g S2VudCA8Z2xlbi5rZW50QGdtYWlsLmNvbT4gd3JvdGU6DQo+IFNvbWUgbW9yZSByZWFzb25zIGZv ciBnb2luZyBpbiBmb3IgbXVsdGljYXN0IGdpdmVuIGF0IHRoZSBlbmQgb2YgdGhlIA0KPiBuZXcg dmVyc2lvbi4NCj4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW1tLWJmZC1v bi1sYWdzLTAxI2FwcGVuZGl4LUEuMQ0KPg0KPiBJIGRvbnQgdGhpbmsgdGhlcmUgaXMgYSBuZWVk IHRvIHNwZWNpZnkgdGhhdCB0aGUgVFRMPTEgc2luY2UgdGhlIA0KPiBtdWx0aWNhc3QgYWRkcmVz c2VzIGhhdmUgYSBsaW5rIGxvY2FsIHNjb3BlLiBBbSBpIG1pc3Npbmcgc29tZXRoaW5nPw0KPg0K PiBUaGFua3MsDQo+IEdsZW4NCj4NCj4gT24gVHVlLCBEZWMgMjAsIDIwMTEgYXQgNTowOCBBTSwg TWFyYyBCaW5kZXJiZXJnZXIgPG1hcmNAc25pZmYuZGU+IHdyb3RlOg0KPj4gSGVsbG8gTm9ibywN Cj4+DQo+Pj4gSSBzZWUgbmV3IHJldmlzaW9uIG91dCB0aGVyZSwgd2lsbCBoYXZlIHRvIGdvIGNo ZWNrIGl0IG91dC4NCj4+DQo+PiBUaGFua3MgZm9yIHRoZSBpbnRlcmVzdCA6LSkNCj4+DQo+Pg0K Pj4+IFRoZSBvdGhlciBxdWVzdGlvbiB0aGF0IEkgaGF2ZSBvbiB0aGlzIGRyYWZ0IGlzLCBkbyB3 ZSByZWFsbHkgDQo+Pj4gbmVlZC93YW50IHRvIHJlc2VydmUgSVAgbXVsdGljYXN0IGFkZHJlc3Mg Zm9yIHRoaXMgcHVycG9zZS4gTW9zdCANCj4+PiBjYXNlcywgaWYgbm90IGFsbCwgd2hlcmUgb3Bl cmF0b3Igd2FudHMgdG8gdXNlIEJGRCB0byBwcm90ZWN0IExBRyBhdCANCj4+PiBtZW1iZXIgbGV2 ZWwgc2hvdWxkIGhhdmUgc29tZSBzb3J0IG9mIElQIGFkZHJlc3MgYXNzaWduZWQgYXQgTEFHLg0K Pj4NCj4+IEkgaGF2ZSBzZWVuIHRoZXJlIGhhZCBiZWVuIHNvbWUgInVubnVtYmVyZWQiIGRpc2N1 c3Npb24gYnV0IGFjdHVhbGx5IHRoYXQgaXMgbm90IHRoZSByZWFzb24uIEFjdHVhbGx5ICJ1bm51 bWJlcmVkIiB3YXMgcHV0IGFzaWRlIHdoZW4gd2UgZGlzY3Vzc2VkIHRoZSBvcmlnaW5hbCBkcmFm dC1jaGVuLWJmZC1pbnRlcmZhY2UgYW5kIHRoZSBsaXN0IGZlZWRiYWNrIHdhcyB0byBmb2N1cyBv biBMQUcgd2l0aCBJUCBhdCB0aGF0IHRpbWUuDQo+Pg0KPj4NCj4+IFdoYXQgd2Ugd2FudCB0byBh Y2hpZXZlOg0KPj4NCj4+IC0geW91IGNhbiBoYXZlIGEgbWVtYmVyLWxpbmsgc2Vzc2lvbiAoYWth ICJtaWNybyBzZXNzaW9uIikNCj4+IC0geW91IGNhbiBoYXZlIGFkZGl0aW9uYWxseSBhIEJCUCBz ZXNzaW9uICh0aGUgc2luZ2xlIHNlc3Npb24gb3ZlciANCj4+IExBRykgZm9yIHRoZSBtYWluIExB RyBpbnRlcmZhY2UNCj4+DQo+PiBPbiB0aGUgcmVjZWl2aW5nIHNpZGUsIHdoYXQgZG8geW91IGRv IHRvIGRpZmZlcmVudGlhdGUgdGhlc2Ugc2Vzc2lvbnMgKHRoaW5rIGFib3V0IHRoZSB5b3VyX2Rp c2NyIHplcm8gY2FzZSk/DQo+Pg0KPj4gKGkpIGRpZmZlcmVudCBhZGRyZXNzDQo+PiAoaWkpIGRp ZmZlcmVudCBVRFAgcG9ydA0KPj4NCj4+DQo+PiBCb3RoIHNob3VsZCB3b3JrLiBXZSBzdGFydGVk IHRoZSBkcmFmdCB3aXRoIChpKSBpbiBtaW5kIGFuZCBJIGRvbid0IHNlZSBhIGhhcmQgcmVhc29u IHRvIGNoYW5nZSB0aGlzLg0KPj4NCj4+IEZvciAoaSkgeW91IHRoZW4gY29tZSB1cCB3aXRoIHRo ZSBpZGVhIG9mIGEgImRlZGljYXRlZCBhZGRyZXNzIi4gMTI3Lzggd2FzIHByb3Bvc2VkIGJ5IEdy ZWdvcnkgYW5kIGFnYWluLCB0aGF0IHdvdWxkIHdvcmsgYWx0aG91Z2ggLi4uIGhvdyBkbyB5b3Ug ZGlmZmVyZW50aWF0ZSB0aGlzIGZyb20gYSBCRkQtTFNQIChSRkZDNTg4NCkgcGFja2V0IGFycml2 aW5nIG9uIHRoZSBMQUcgaW50ZXJmYWNlPyDCoFNvIGEgTXVsdGljYXN0IGFkZHJlc3Mgc2VlbXMg YW5vdGhlciBvcHRpb24uDQo+Pg0KPj4NCj4+PiBSZXN1bHRpbmcgYmVoYXZpb3Igd2lsbCBiZSBs ZXNzIGRldmlhdGluZyBmcm9tIFJGQzU4ODE6IHNhbWUgZGVtdXggDQo+Pj4gcHJvY2VkdXJlcyBj YW4gYmUgdXNlZCB3aGVuIGRpc2NyaW1pbmF0b3IgaXMgemVybygwKSwNCj4+DQo+PiBzbyBjYW4g aXQgZm9yIHRoZSBsaW5rLWxvY2FsIG11bHRpaG9wIGFkZHJlc3MgSSB0aGluayAtIG5vPyBOb3cg d2UgZG8gbWVudGlvbiB0aGlzIGluIHNlY3Rpb24gMy4yLCBhcyBhIHJlbWluZGVyIHRoYXQgZm9y IHlvdXJfRGlzY3IgemVybyB0aGUgbWFpbiBkaWZmZXJlbmNlIGlzIHRoZSBpbmdyZXNzIGludGVy ZmFjZToNCj4+DQo+PiDCoCBUaGUgZGVtdWx0aXBsZXhpbmcgb2YgYSByZWNlaXZlZCBwYWNrZXQg aXMgc29sZWx5IGJhc2VkIG9uIHRoZSBZb3VyDQo+PiDCoCBEaXNjcmltaW5hdG9yIGZpZWxkLCBp ZiB0aGlzIGZpZWxkIGlzIG5vbnplcm8uIMKgRm9yIHRoZSBpbml0aWFsIA0KPj4gRG93bg0KPj4g wqAgcGFja2V0IG9mIGEgbWljcm8gc2Vzc2lvbiB0aGlzIHZhbHVlIG1heSBiZSB6ZXJvLiDCoElu IHRoaXMgY2FzZQ0KPj4gwqAgZGVtdWx0aXBsZXhpbmcgTVVTVCBiZSBiYXNlZCBvbiBzb21lIGNv bWJpbmF0aW9uIG9mIG90aGVyIGZpZWxkcw0KPj4gwqAgd2hpY2ggTVVTVCBpbmNsdWRlIHRoZSBp bnRlcmZhY2UgaW5mb3JtYXRpb24gb2YgdGhlIG1lbWJlciBsaW5rLg0KPj4NCj4+DQo+Pj4gbm8g bmVlZCB0bw0KPj4+IGNvbWUgdXAgd2l0aCBzcGVjaWFsIGNhc2Ugb2YgVFRMPTEgd2hpY2ggd2Fz IGRpc2N1c3NlZC4NCj4+DQo+Pg0KPj4gb2gtb2ggSSBtaXNzZWQgdGhpcyBwYXJ0ISBIYXZlIHRv IGdvIHRocm91Z2ggdGhlIGVtYWlscy4gVFRMID0gMSA/IT8gwqANCj4+IE91ciBkcmFmdCBpcyBu b3QgdGFsa2luZyBhYm91dCB0aGlzIChzZWN0aW9uIDMgbWVudGlvbnMgUkZDNTg4MCwgc28gDQo+ PiB5b3Ugd291bGQgaGF2ZSBhIFRUTCBvZiAyNTUpDQo+Pg0KPj4NCj4+PiBJJ20gcXVlc3Rpb25p bmcNCj4+PiB0aGlzIGFzcGVjdCBzaW5jZSBJIGRpZG4ndCBzZWUgYW55IHN0cm9uZyBhcmd1bWVu dHMgZm9yIGJ1cm5pbmcgdXAgDQo+Pj4gSVAgbXVsdGljYXN0IGFkZHJlc3MuDQo+Pg0KPj4gYWN0 dWFsbHkgSSB3b25kZXIgaWYgYWxsLXJvdXRlciBvciBhbGwtaG9zdHMgd291bGRuJ3QgZG8gdGhl IGpvYi4gV2UgY291bGQgcHJvYmFibHkgZXZlbiB1c2UgMjU1LjI1NS4yNTUuMjU1IGFzIHRoZSBz ZXR1cCBpcyBhIGRpcmVjdCBsaW5rLCBiYWNrIHRvIGJhY2suIE9wZW4gdG8gdGhpcy4gQnV0IGlm IGl0IHR1cm5zIG91dCB3ZSBuZWVkIG9uZSwgd2VsbCB0aGVuIHdlIG5lZWQgb25lLiBPciBhbHRl cm5hdGl2ZWx5IC0gc2VlIChpaSkgYWJvdmUgLSBhIG5ldyBJQU5BIFVEUCBwb3J0LiBOb3Qgc3Vy ZSB3aGF0IGlzIGJldHRlci93b3JzZS4NCj4+DQo+Pg0KPj4gUmVnYXJkcywgTWFyYw0KPj4NCj4+ DQo+Pg0KPj4NCj4+Pg0KPj4+IFRoYW54LA0KPj4+IE5vYm8NCj4+Pg0KPj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBNYXJjIEJpbmRlcmJlcmdlciBbbWFpbHRvOm1h cmNAc25pZmYuZGVdDQo+Pj4+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTksIDIwMTEgNTozMyBQ TQ0KPj4+PiBUbzogTm9ibyBBa2l5YSAobm9ibykNCj4+Pj4gQ2M6IEFsZXhhbmRlciBWYWluc2h0 ZWluOyBEYXZlIEthdHo7IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IEJGRCBv biBMQUcgaW50ZXJmYWNlcw0KPj4+Pg0KPj4+PiBIZWxsbyBOb2JvLA0KPj4+Pg0KPj4+PiB0aGFu a3MgZm9yIHRoZSBjb21tZW50cy4gTGV0IG1lIGNoZWNrIHRoaXMgd2l0aCB0aGUgbmV3IHZlcnNp b24gd2UgDQo+Pj4+IGFyZSBqdXN0IHByZXBhcmluZyAoYWxtb3N0IGRvbmUpLg0KPj4+Pg0KPj4+ PiBBbmQgeWVzLCBhIGNsZWFuZXIgZGVzY3JpcHRpb24gd2hlbiB0aGUgY3JlYXRpb24vZGVsZXRp b24gaXMgcGFydCANCj4+Pj4gb2YNCj4+PiBpdC4NCj4+Pj4gQnV0IEkgYWxzbyB0aGluayB0aGlz IGlzIHdoZXJlIEFsZXhhbmRlcidzIGNvbW1lbnQgY2FtZSBmcm9tOiANCj4+Pj4gd2l0aG91dCBz b21lIG1vZGlmaWNhdGlvbnMgaW4gODAyLjFBWCBpdCB3aWxsIG5vdCBiZSBwb3NzaWJsZSB0byAN Cj4+Pj4gbG9jayB0aGUNCj4+PiAiZ29pbmcNCj4+Pj4gVVAiIHdpdGggQkZELiBPdGhlcndpc2Ug eW91IGFsd2F5cyBydW4gaW50byBxdWVzdGlvbnMgYW5kIGlzc3VlcyAtDQo+Pj4gc3RhcnRpbmcN Cj4+Pj4gTEFDUCBmaXJzdD8gT3IgQkZEIGZpcnN0PyBPciBib3RoIGluIHBhcmFsbGVsPw0KPj4+ Pg0KPj4+Pg0KPj4+Pj4gR2VuZXJhbGx5IHNwZWFraW5nLCB3aGVuIHVwL2Rvd24gdXNlIGRpZmZl cmVudCBtZXRob2RzLCBJJ3ZlIHNlZW4gDQo+Pj4+PiBhIHN5c3RlbSBmYWxsIGludG8gY29udGlu dW91cyBmbGFwIGN5Y2xlLiBEb3duIGJ5IEJGRCwgdXAgYnkNCj4+PiBwcm90b2NvbC9MTU0NCj4+ Pj4+IGlzIG9uZSBwb3NzaWJsZSBhcHByb2FjaCwgYW5kIHlvdXIgZHJhZnQgd2FudHMgdG8gYWxs b3cgdGhpcyBmb3IgDQo+Pj4+PiBpbnRlcm9wZXJhYmlsaXR5IHB1cnBvc2UuIEkgY2FuIHVuZGVy c3RhbmQgdGhlIG5lZWQsIGJ1dCBzaWRlIA0KPj4+Pj4gZWZmZWN0DQo+Pj4+IGNhbg0KPj4+Pj4g YmUgbmFzdHksIGFuZCBpdCAocG9zc2libGUgY29udGludW91cyBmbGFwKSBjYW4gYmUgZGVzY3Jp YmVkPw0KPj4+Pg0KPj4+Pg0KPj4+PiAqc2lnaCogeWVzIC4uLiBtYXliZSB3ZSBzaG91bGQgd3Jp dGUgYSBkcmFmdCBvbiBmbGFwIGRhbXBlbmluZz8gOi0pDQo+Pj4+DQo+Pj4+DQo+Pj4+IExldCBt ZSBnbyB0aHJvdWdoIG91ciBsYXRlc3QgKGludGVybmFsKSB2ZXJzaW9uIGlmIHRoYXQgYWRkcmVz c2VzIA0KPj4+PiB5b3VyIHBvaW50cy4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhhbmtzIQ0KPj4+Pg0K Pj4+PiBSRWdhcmRzLCBNYXJjDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IE9uIDIwMTEt MTItMTksIGF0IDI6NTkgLCBOb2JvIEFraXlhIChub2JvKSB3cm90ZToNCj4+Pj4NCj4+Pj4+IEhl bGxvLA0KPj4+Pj4NCj4+Pj4+IFNlY3Rpb24gMy4yLg0KPj4+Pj4NCj4+Pj4+PiBBIG1lbWJlciBs aW5rIG9mIHRoZSBMQUcgaXMgbm90IHVzZWQgYW55bW9yZSBmb3IgZGF0YSBmb3J3YXJkaW5nDQo+ Pj4+PiB3aGVuDQo+Pj4+Pj4gdGhlIHBhcnRpY3VsYXIgQkZEIHNlc3Npb24gcnVubmluZyBvdmVy IHRoYXQgbGluayBnb2VzIGRvd24uIMKgVGhlIA0KPj4+Pj4+IG1lbWJlciBsaW5rIE1VU1QgYmUg cmVtb3ZlZCBmcm9tIHRoZSBMQUcuIMKgVGhlIEJGRCBzZXNzaW9uIGZvciANCj4+Pj4+PiB0aGUg bGluayByZW1haW5zLCBpLmUuIGl0IGlzIG5vdCBkZWxldGVkLg0KPj4+Pj4NCj4+Pj4+IEl0IGlz IG5vdCBjbGVhciB3aGVuIEJGRCBzZXNzaW9uIHNob3VsZCBnZXQgZGVsZXRlZCAobm9yIGNyZWF0 ZWQpLg0KPj4+IFdpdGgNCj4+Pj4+IGFib3ZlIHN0YXRlbWVudCwgQkZEIHNlc3Npb24gY291bGQg cmVtYWluIGV2ZW4gd2hlbiBvcGVyYXRvciANCj4+Pj4+IGRlY2lkZXMNCj4+Pj4gdG8NCj4+Pj4+ IHNodXQgZG93biBhIG1lbWJlciwgZGVwZW5kaW5nIG9uIGhvdyBpdCdzIGludGVycHJldGVkL2lt cGxlbWVudGVkLg0KPj4+IFdoZW4NCj4+Pj4+IExBQ1AgaXMgdXNlZCwgTE1NIHdpbGwgc3RhcnR1 cCBMQUNQIG9ubHkgd2hlbiBpbnRlcmZhY2UgaXMgdXAuIEwyDQo+Pj4gY2hlY2sNCj4+Pj4+IHN0 YXJ0cyBvbmx5IHdoZW4gTDEgY2hlY2sgcGFzc2VzLiBDaGVjayBpcyBkb25lIGZyb20gYm90dG9t IGxheWVyIA0KPj4+Pj4gdXB3YXJkcy4gR29pbmcgYnkgc2FtZSBpZGVhLCBCRkQgc2Vzc2lvbiBz aG91bGQgb25seSBiZSBjcmVhdGVkIA0KPj4+Pj4gd2hlbg0KPj4+PiBMMg0KPj4+Pj4gY2hlY2sg cGFzc2VzIChMQUNQKSwgd2hlbiBMMiBjaGVjayBpcyBiZWluZyB1c2VkLiBJZiBMMiBjaGVjayBp cyANCj4+Pj4+IG5vdCBiZWluZyB1c2VkLCB0aGVuIEwxIGNoZWNrIGlzIHJlcXVpcmVkIGZvciBC RkQgc2Vzc2lvbiB0byBnZXQNCj4+PiBjcmVhdGVkLg0KPj4+Pj4gQWJzZW5jZSBpbiBMMS9MMiBj aGVjayBwYXNzIHNob3VsZCBjYXVzZSBjb3JyZXNwb25kaW5nIEJGRCANCj4+Pj4+IHNlc3Npb25z DQo+Pj4+IHRvDQo+Pj4+PiBnZXQgZGVsZXRlZC4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+PiAzLiBU aGUgc2l0dWF0aW9uIHdoZW4gTEFHIGdvZXMgZG93biBkdWUgdG8gaW5zdWZmaWNpZW50IG51bWJl ciANCj4+Pj4+Pj4gb2YNCj4+Pj4+IGFjdGl2ZQ0KPj4+Pj4+IGxpbmtzIG11c3QgYmUgcmV2ZXJz aWJsZSwgaS5lLiwgdGhlIExBRyBtdXN0IGJlIGFibGUgdG8gZ28gVVAgDQo+Pj4+Pj4gb25jZQ0K Pj4+Pj4gdGhpcw0KPj4+Pj4+IGNvbmRpdGlvbiBkaXNhcHBlYXJzLg0KPj4+Pj4+DQo+Pj4+Pj4g eWVzLCBJIHdvdWxkIHByZWZlciB0aGlzIDstKQ0KPj4+Pj4+DQo+Pj4+Pj4+IERvIHRoZXNlIG5v dGVzIGNhcHR1cmUgdGhlIHByb2JsZW0gc3BhY2UgY29ycmVjdGx5PyBPciBkaWQgSSANCj4+Pj4+ Pj4gbWlzcw0KPj4+Pj4+IHNvbWV0aGluZyBpbXBvcnRhbnQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9u ZSBwb2ludCB0aGF0IGlzIG5vdCBjbGVhciB0byBtZSBpcyB0aGUgdGltZWZyYW1lIGZvciBicmlu Z2luZw0KPj4+Pj4+IGNvbnN0aXR1ZW50IGxpbmtzIG9mIGEgTEFHIHVwLiBJIHdvdWxkIGV4cGVj dCB0aGF0IHRoZSANCj4+Pj4+PiByZXF1aXJlbWVudHMNCj4+Pj4+IGZvcg0KPj4+Pj4+IHRoYXQg Y291bGQgYmUgbXVjaCBtb3JlIHJlbGF4ZWQgKGUuZy4sIGluIG9yZGVyIHRvIGF2b2lkIGxpbmsN Cj4+Pj4+IGZsYXBwaW5nKS4NCj4+Pj4+PiBJcyB0aGF0IGNvcnJlY3Q/IElmIGl0IGlzLCBvbmUg cG9zc2libGUgaW1wbGljYXRpb24gaXMgdGhhdCBpdCBpcw0KPj4+Pj4gcG9zc2libGUNCj4+Pj4+ PiB0byB1c2UgZGlmZmVyZW50IG1lY2hhbmlzbXMgZm9yIGJyaW5naW5nIGxpbmtzIERPV04gYW5k IFVQLiBUbyANCj4+Pj4+PiB0aGUNCj4+Pj4+IGJlc3QNCj4+Pj4+PiBvZiBteSB1bmRlcnN0YW5k aW5nLCB0aGlzIGlzIGhvdyBCRkQgaXMgc3VwcG9zZWQgdG8gYmUgdXNlZCB3aXRoDQo+Pj4+PiBy b3V0aW5nDQo+Pj4+Pj4gYWRqYWNlbmNpZXMgdG9kYXksIGkuZS4gQkZEIGNhbiBicmluZyB0aGUg YWRqYWNlbmN5IERPV04gcXVpdGUNCj4+PiBmYXN0LA0KPj4+Pj4gYnV0DQo+Pj4+Pj4gaXQgaGFz IHRvIGJlIGJyb3VnaHQgVVAgYnkgdGhlIGFwcHJvcHJpYXRlIHJvdXRpbmcgcHJvdG9jb2wuDQo+ Pj4+Pj4NCj4+Pj4+PiB0aGUgZHJhZnQgYWxsb3dzIHRoaXMsIHNlY3Rpb24gMy4yICJUbyBhdm9p ZCB0aGlzIGRlYWRsb2NrIC4uLiIuIA0KPj4+Pj4+IFNvDQo+Pj4+PiB1c2luZw0KPj4+Pj4+IEJG RCB0byBicmluZyBkb3duIGZhc3QgYWxvbmUgaXMgY292ZXJlZC4gTm93IFJGQzU4ODIsIGUuZy4g DQo+Pj4+Pj4gc2VjdGlvbg0KPj4+Pj4gNC4xLA0KPj4+Pj4+IG1lbnRpb25zIHRoYXQgd2FpdGlu ZyBmb3IgQkZEJ3MgVXAgbm90aWZpY2F0aW9uIG1heSBiZSB1c2VmdWwuIA0KPj4+Pj4+IFRodXMN Cj4+Pj4gd2UNCj4+Pj4+PiBhbGxvd2VkIHRoaXMgaW4gdGhlIGRyYWZ0IGFzIHdlbGwuDQo+Pj4+ Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFtJIHNraXAgdGhlIExBQ1AsIENGTSBwYXJ0LiBXZSBoYWQgdGhp cy4gTm90aGluZyB3cm9uZyANCj4+Pj4+PiB0ZWNobmljYWxseQ0KPj4+PiBidXQNCj4+Pj4+PiBz b21laG93IGN1c3RvbWVycyBwdXNoIEJGRCB0ZWFtcyB0byBkZWxpdmVyXQ0KPj4+Pj4NCj4+Pj4+ IEdlbmVyYWxseSBzcGVha2luZywgd2hlbiB1cC9kb3duIHVzZSBkaWZmZXJlbnQgbWV0aG9kcywg SSd2ZSBzZWVuIA0KPj4+Pj4gYSBzeXN0ZW0gZmFsbCBpbnRvIGNvbnRpbnVvdXMgZmxhcCBjeWNs ZS4gRG93biBieSBCRkQsIHVwIGJ5DQo+Pj4gcHJvdG9jb2wvTE1NDQo+Pj4+PiBpcyBvbmUgcG9z c2libGUgYXBwcm9hY2gsIGFuZCB5b3VyIGRyYWZ0IHdhbnRzIHRvIGFsbG93IHRoaXMgZm9yIA0K Pj4+Pj4gaW50ZXJvcGVyYWJpbGl0eSBwdXJwb3NlLiBJIGNhbiB1bmRlcnN0YW5kIHRoZSBuZWVk LCBidXQgc2lkZSANCj4+Pj4+IGVmZmVjdA0KPj4+PiBjYW4NCj4+Pj4+IGJlIG5hc3R5LCBhbmQg aXQgKHBvc3NpYmxlIGNvbnRpbnVvdXMgZmxhcCkgY2FuIGJlIGRlc2NyaWJlZD8NCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4gU2VjdGlvbiA0LCBmaXJzdCBidWxsZXQuDQo+Pj4+Pg0KPj4+Pj4gTEFHIHdp bGwgYmUgdGFrZW4gZG93biB3aGVuIEJGRCBmYWlscyBvbiBzdWZmaWNpZW50IG1lbWJlcnMgKExB RyANCj4+Pj4+IGludGVyZmFjZSBzdGF0ZSB3aWxsIGJlIGRvd24pLiBMQUcgd2lsbCBjb21lIHVw IHBvdGVudGlhbGx5IHdoZW4gDQo+Pj4+PiBCRkQNCj4+Pj4gb24NCj4+Pj4+IHN1ZmZpY2llbnQg bWVtYmVycyBjb21lIHVwIChMQUcgaW50ZXJmYWNlIHN0YXRlIHdpbGwgYmUgdXApLiBUaGlzIA0K Pj4+Pj4gYmVoYXZpb3IgaW1wbGllcyB0aGF0IGFsbCBhcHBsaWNhdGlvbnMgd2lsbCBiZW5lZml0 IChieSBtb25pdG9yaW5nDQo+Pj4gTEFHDQo+Pj4+PiBpbnRlcmZhY2Ugc3RhdGUpIGV2ZW4gaWYg dGhvc2UgYXBwbGljYXRpb25zIGRvIG5vdCBjb25maWd1cmUgQkZEIA0KPj4+Pj4gb24NCj4+Pj4g TEFHLg0KPj4+Pj4gU3VyZSwgb25lIGNhbiBjb25maWd1cmUgYXBwbGljYXRpb25zIHdpdGggQkZE IG92ZXIgTEFHLCBidXQgdGhhdCdzDQo+Pj4gbm90DQo+Pj4+PiBhbiBhYnNvbHV0ZSByZXF1aXJl bWVudCBmb3IgdGhpcyBtb2RlbC4gU3RhdGVtZW50cyByZWdhcmRpbmcgdGhpcyANCj4+Pj4+IGJl aGF2aW9yIHdpbGwgYmUgYmVuZWZpY2lhbCB0byByZWFkZXJzLg0KPj4+Pj4NCj4+Pj4+IFRoYW54 LA0KPj4+Pj4gTm9ibw0KPj4+Pj4NCj4+Pj4NCj4+Pj4gLS0NCj4+Pj4gTWFyYyBCaW5kZXJiZXJn ZXIgwqAgwqAgwqAgwqAgwqAgPG1hcmNAc25pZmYuZGU+DQo+Pj4NCj4+DQo+PiAtLQ0KPj4gTWFy YyBCaW5kZXJiZXJnZXIgwqAgwqAgwqAgwqAgwqAgPG1hcmNAc25pZmYuZGU+DQo+Pg0KDQoNCg0K LS0NClRvbXMuDQo= From toms.sanders@gmail.com Wed Dec 21 17:16: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 E57F211E80E6 for ; Wed, 21 Dec 2011 17:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEQA2UIkA0kC for ; Wed, 21 Dec 2011 17:16:51 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84D3411E80C0 for ; Wed, 21 Dec 2011 17:16:50 -0800 (PST) Received: by wibhj6 with SMTP id hj6so2758004wib.31 for ; Wed, 21 Dec 2011 17:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fh0xn2AGF2YH5RMP/7axsPL7uy1d1IW/xUas+9ooPkw=; b=TkNz7ZZIWrCp/yejiRIojumX6d0Io/+hf62AdQViqZs1jBwZssQPTlizhnAz9Ucuby JqAsp/c8MGLozzNyVeXnAuPxxDSK8zJe3chQCmHbMT4Jq2TniTVHmxBAVlzL8HLVXDpI 5cNctrlQQH4pI3JzH6uJYK2wBNYqE8P6727a8= MIME-Version: 1.0 Received: by 10.180.19.74 with SMTP id c10mr18771106wie.8.1324516609508; Wed, 21 Dec 2011 17:16:49 -0800 (PST) Received: by 10.223.89.12 with HTTP; Wed, 21 Dec 2011 17:16:49 -0800 (PST) In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C5694C2@EUSAACMS0701.eamcs.ericsson.se> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C5694C2@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 22 Dec 2011 06:46:49 +0530 Message-ID: Subject: Re: Multicast vs Unicast (was BFD on LAG interfaces) From: Tom Sanders To: Jeff Tantsura Content-Type: text/plain; charset=UTF-8 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: Thu, 22 Dec 2011 01:16:52 -0000 Oh and btw, i would too prefer option (1a), i.e. going the multicast way. Toms On 22 December 2011 06:28, Jeff Tantsura wrote= : > Hi, > > /*customer/product manager mode*/ > If we set aside religious discussion about layer violation/etc IMHO 1a is= just fine, it allows reusing existing BFD implementations with minimum cha= nges, hence decreases time to market =3D=3D happy customers. > I think we should still be keeping our focus on IP LAG, as we are trying = to extend RFC5881 to work over LAG where BFD is used is to track IPv4 and I= Pv6 connectivity between directly connected systems > IMO for L2 LAG Eth OAM would make much more sense (eg. .1ag aware LAG). > > Regards, > Jeff > > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f Of Tom Sanders > Sent: Wednesday, December 21, 2011 4:31 PM > To: rtg-bfd@ietf.org > Subject: Multicast vs Unicast (was BFD on LAG interfaces) > > The two options before the WG are: > > 1. Use IP encapsulation > 2. Use direct L2 encapsulation. > > With (1) we have an option of (1a) Using Multicast and (1b) Using Unicast= . > > Can we arrive on a consensus between choosing 1a and 1b? > > Given that the new draft has this nice Appendix that succinctly discusses= this, can the proponents of (1b) justify why they think (1a) is not good e= nough. > > Lets try closing the different threads so that we can converge towards a = solution. > > Toms > > On 20 December 2011 06:24, Glen Kent wrote: >> Some more reasons for going in for multicast given at the end of the >> new version. >> >> http://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >> >> I dont think there is a need to specify that the TTL=3D1 since the >> multicast addresses have a link local scope. Am i missing something? >> >> Thanks, >> Glen >> >> On Tue, Dec 20, 2011 at 5:08 AM, Marc Binderberger wrote= : >>> Hello Nobo, >>> >>>> I see new revision out there, will have to go check it out. >>> >>> Thanks for the interest :-) >>> >>> >>>> The other question that I have on this draft is, do we really >>>> need/want to reserve IP multicast address for this purpose. Most >>>> cases, if not all, where operator wants to use BFD to protect LAG at >>>> member level should have some sort of IP address assigned at LAG. >>> >>> I have seen there had been some "unnumbered" discussion but actually th= at is not the reason. Actually "unnumbered" was put aside when we discussed= the original draft-chen-bfd-interface and the list feedback was to focus o= n LAG with IP at that time. >>> >>> >>> What we want to achieve: >>> >>> - you can have a member-link session (aka "micro session") >>> - you can have additionally a BBP session (the single session over >>> LAG) for the main LAG interface >>> >>> On the receiving side, what do you do to differentiate these sessions (= think about the your_discr zero case)? >>> >>> (i) different address >>> (ii) different UDP port >>> >>> >>> Both should work. We started the draft with (i) in mind and I don't see= a hard reason to change this. >>> >>> For (i) you then come up with the idea of a "dedicated address". 127/8 = was proposed by Gregory and again, that would work although ... how do you = differentiate this from a BFD-LSP (RFFC5884) packet arriving on the LAG int= erface? =C2=A0So a Multicast address seems another option. >>> >>> >>>> Resulting behavior will be less deviating from RFC5881: same demux >>>> procedures can be used when discriminator is zero(0), >>> >>> so can it for the link-local multihop address I think - no? Now we do m= ention this in section 3.2, as a reminder that for your_Discr zero the main= difference is the ingress interface: >>> >>> =C2=A0 The demultiplexing of a received packet is solely based on the Y= our >>> =C2=A0 Discriminator field, if this field is nonzero. =C2=A0For the ini= tial >>> Down >>> =C2=A0 packet of a micro session this value may be zero. =C2=A0In this = case >>> =C2=A0 demultiplexing MUST be based on some combination of other fields >>> =C2=A0 which MUST include the interface information of the member link. >>> >>> >>>> no need to >>>> come up with special case of TTL=3D1 which was discussed. >>> >>> >>> oh-oh I missed this part! Have to go through the emails. TTL =3D 1 ?!? >>> Our draft is not talking about this (section 3 mentions RFC5880, so >>> you would have a TTL of 255) >>> >>> >>>> I'm questioning >>>> this aspect since I didn't see any strong arguments for burning up >>>> IP multicast address. >>> >>> actually I wonder if all-router or all-hosts wouldn't do the job. We co= uld probably even use 255.255.255.255 as the setup is a direct link, back t= o back. Open to this. But if it turns out we need one, well then we need on= e. Or alternatively - see (ii) above - a new IANA UDP port. Not sure what i= s better/worse. >>> >>> >>> Regards, Marc >>> >>> >>> >>> >>>> >>>> Thanx, >>>> Nobo >>>> >>>>> -----Original Message----- >>>>> From: Marc Binderberger [mailto:marc@sniff.de] >>>>> Sent: Monday, December 19, 2011 5:33 PM >>>>> To: Nobo Akiya (nobo) >>>>> Cc: Alexander Vainshtein; Dave Katz; rtg-bfd@ietf.org >>>>> Subject: Re: BFD on LAG interfaces >>>>> >>>>> Hello Nobo, >>>>> >>>>> thanks for the comments. Let me check this with the new version we >>>>> are just preparing (almost done). >>>>> >>>>> And yes, a cleaner description when the creation/deletion is part >>>>> of >>>> it. >>>>> But I also think this is where Alexander's comment came from: >>>>> without some modifications in 802.1AX it will not be possible to >>>>> lock the >>>> "going >>>>> UP" with BFD. Otherwise you always run into questions and issues - >>>> starting >>>>> LACP first? Or BFD first? Or both in parallel? >>>>> >>>>> >>>>>> Generally speaking, when up/down use different methods, I've seen >>>>>> a system fall into continuous flap cycle. Down by BFD, up by >>>> protocol/LMM >>>>>> is one possible approach, and your draft wants to allow this for >>>>>> interoperability purpose. I can understand the need, but side >>>>>> effect >>>>> can >>>>>> be nasty, and it (possible continuous flap) can be described? >>>>> >>>>> >>>>> *sigh* yes ... maybe we should write a draft on flap dampening? :-) >>>>> >>>>> >>>>> Let me go through our latest (internal) version if that addresses >>>>> your points. >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> REgards, Marc >>>>> >>>>> >>>>> >>>>> >>>>> On 2011-12-19, at 2:59 , Nobo Akiya (nobo) wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Section 3.2. >>>>>> >>>>>>> A member link of the LAG is not used anymore for data forwarding >>>>>> when >>>>>>> the particular BFD session running over that link goes down. =C2=A0= The >>>>>>> member link MUST be removed from the LAG. =C2=A0The BFD session for >>>>>>> the link remains, i.e. it is not deleted. >>>>>> >>>>>> It is not clear when BFD session should get deleted (nor created). >>>> With >>>>>> above statement, BFD session could remain even when operator >>>>>> decides >>>>> to >>>>>> shut down a member, depending on how it's interpreted/implemented. >>>> When >>>>>> LACP is used, LMM will startup LACP only when interface is up. L2 >>>> check >>>>>> starts only when L1 check passes. Check is done from bottom layer >>>>>> upwards. Going by same idea, BFD session should only be created >>>>>> when >>>>> L2 >>>>>> check passes (LACP), when L2 check is being used. If L2 check is >>>>>> not being used, then L1 check is required for BFD session to get >>>> created. >>>>>> Absence in L1/L2 check pass should cause corresponding BFD >>>>>> sessions >>>>> to >>>>>> get deleted. >>>>>> >>>>>> >>>>>>>> 3. The situation when LAG goes down due to insufficient number >>>>>>>> of >>>>>> active >>>>>>> links must be reversible, i.e., the LAG must be able to go UP >>>>>>> once >>>>>> this >>>>>>> condition disappears. >>>>>>> >>>>>>> yes, I would prefer this ;-) >>>>>>> >>>>>>>> Do these notes capture the problem space correctly? Or did I >>>>>>>> miss >>>>>>> something important? >>>>>>>> >>>>>>>> One point that is not clear to me is the timeframe for bringing >>>>>>> constituent links of a LAG up. I would expect that the >>>>>>> requirements >>>>>> for >>>>>>> that could be much more relaxed (e.g., in order to avoid link >>>>>> flapping). >>>>>>> Is that correct? If it is, one possible implication is that it is >>>>>> possible >>>>>>> to use different mechanisms for bringing links DOWN and UP. To >>>>>>> the >>>>>> best >>>>>>> of my understanding, this is how BFD is supposed to be used with >>>>>> routing >>>>>>> adjacencies today, i.e. BFD can bring the adjacency DOWN quite >>>> fast, >>>>>> but >>>>>>> it has to be brought UP by the appropriate routing protocol. >>>>>>> >>>>>>> the draft allows this, section 3.2 "To avoid this deadlock ...". >>>>>>> So >>>>>> using >>>>>>> BFD to bring down fast alone is covered. Now RFC5882, e.g. >>>>>>> section >>>>>> 4.1, >>>>>>> mentions that waiting for BFD's Up notification may be useful. >>>>>>> Thus >>>>> we >>>>>>> allowed this in the draft as well. >>>>>>> >>>>>>> >>>>>>> [I skip the LACP, CFM part. We had this. Nothing wrong >>>>>>> technically >>>>> but >>>>>>> somehow customers push BFD teams to deliver] >>>>>> >>>>>> Generally speaking, when up/down use different methods, I've seen >>>>>> a system fall into continuous flap cycle. Down by BFD, up by >>>> protocol/LMM >>>>>> is one possible approach, and your draft wants to allow this for >>>>>> interoperability purpose. I can understand the need, but side >>>>>> effect >>>>> can >>>>>> be nasty, and it (possible continuous flap) can be described? >>>>>> >>>>>> >>>>>> Section 4, first bullet. >>>>>> >>>>>> LAG will be taken down when BFD fails on sufficient members (LAG >>>>>> interface state will be down). LAG will come up potentially when >>>>>> BFD >>>>> on >>>>>> sufficient members come up (LAG interface state will be up). This >>>>>> behavior implies that all applications will benefit (by monitoring >>>> LAG >>>>>> interface state) even if those applications do not configure BFD >>>>>> on >>>>> LAG. >>>>>> Sure, one can configure applications with BFD over LAG, but that's >>>> not >>>>>> an absolute requirement for this model. Statements regarding this >>>>>> behavior will be beneficial to readers. >>>>>> >>>>>> Thanx, >>>>>> Nobo >>>>>> >>>>> >>>>> -- >>>>> Marc Binderberger =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>>> >>> >>> -- >>> Marc Binderberger =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 >>> > > > > -- > Toms. --=20 Toms. From nobo@cisco.com Thu Dec 22 06:47:00 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 A496321F8B2A for ; Thu, 22 Dec 2011 06:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsNz-b+yx-qI for ; Thu, 22 Dec 2011 06:46:56 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D0B0921F8B29 for ; Thu, 22 Dec 2011 06:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=18816; q=dns/txt; s=iport; t=1324565216; x=1325774816; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AUeN6Z6ALGU3dzomroh0Fl9TvGtx6dE2amFDM7GCM7c=; b=XFAzZflOCoHlVFBU5ankkhhUl/eW6B20BipZJp06HH5rFhrjBpp4VBfM ppHitujuxLhHizNCX7o/QBX9PvQBi23krdK6/UMuHn8vf0IbE0Ha5N/xD AcjFLdHW7heMoWWpy1R+HowWHLqrAQ8kzleEEEUoVvF7S1f2pfO6i+Ma0 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0AAFJC806rRDoI/2dsb2JhbABDhQ+WQo81gSWBBYFyAQEBAwESARANBEUFBwQCAQYCEQQBAQECAgYGCQIMAQICAgEBHyUJCAEBBAESCBMHh1gImHoBjFuRXYEvh1cCgXEzYwSIN5c4h2U X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; d="scan'208";a="22082140" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 22 Dec 2011 14:46:56 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBMEkumF012971; Thu, 22 Dec 2011 14:46:56 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 06:46:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: Multicast vs Unicast (was BFD on LAG interfaces) Date: Thu, 22 Dec 2011 06:46:53 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Index: AczAR2ZYRcWugDMCSHGEYjQ1ryTh2wAbeB5g References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C5694C2@EUSAACMS0701.eamcs.ericsson.se> From: "Nobo Akiya (nobo)" To: "Tom Sanders" , "Jeff Tantsura" X-OriginalArrivalTime: 22 Dec 2011 14:46:55.0994 (UTC) FILETIME=[8D0E45A0:01CCC0B8] 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, 22 Dec 2011 14:47:00 -0000 DQpIZWxsbyBUb20sIEplZmYsIGV0IGFsLA0KDQpJIGZlZWwgb2JsaWdhdGVkIHRvIHJlcGx5IHRv IHRoaXMgdGhyZWFkLCBzbyBoZXJlIHdlIGdvLg0KDQo+IHRvIHdvcmsgb3ZlciBMQUcgd2hlcmUg QkZEIGlzIHVzZWQgaXMgdG8gdHJhY2sgSVB2NA0KPiBhbmQgSVB2NiBjb25uZWN0aXZpdHkgYmV0 d2VlbiBkaXJlY3RseSBjb25uZWN0ZWQgc3lzdGVtcw0KDQpDb3JlIGlkZWEgb2YgcnVubmluZyBC RkQgcGVyIG1lbWJlciBpcyBmb3IgbGluayB2ZXJpZmljYXRpb24sIG5vdCBmb3IgSVB2NCBhbmQg SVB2NiBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uLiBIb3dldmVyLCBkZXBlbmRpbmcgb24gaG93 IGl0J3MgaW1wbGVtZW50ZWQsIHlvdSBjb3VsZCB2ZXJpZnkgcGllY2VzIG9mIElQIGZvcndhcmRp bmcsIGFuZCB0aGlzIHdpbGwgYmUgbW9yZSBwb3NzaWJsZSBpZiB1bmljYXN0IGFuZCBhY3R1YWxs eSA4MDIuMWF4IGFzc2lnbmVkIElQIGFkZHJlc3Mgd2FzIHRvIGJlIHVzZWQuDQoNCj4gPiBJIHRo aW5rIHdlIHNob3VsZCBzdGlsbCBiZSBrZWVwaW5nIG91ciBmb2N1cyBvbiBJUCBMQUcsIGFzIHdl IGFyZSB0cnlpbmcNCj4gdG8gZXh0ZW5kIFJGQzU4ODEgdG8gd29yayBvdmVyIExBRw0KDQpXZSB3 aWxsIGhhdmUgbWlub3IgZGlmZmVyZW5jZXMgd2l0aCBSRkM1ODgxIHdoZW4gd2Ugc3RhcnQgdXNp bmcgbXVsdGljYXN0IGFkZHJlc3MuDQoNCkZvciBleGFtcGxlOg0KDQogICBPbiBhIG11bHRpYWNj ZXNzIG5ldHdvcmssIEJGRCBDb250cm9sIHBhY2tldHMgTVVTVCBiZSB0cmFuc21pdHRlZA0KICAg d2l0aCBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyB0aGF0IGFyZSBwYXJ0IG9mIHRo ZSBzdWJuZXQNCiAgIChhZGRyZXNzZWQgZnJvbSBhbmQgdG8gaW50ZXJmYWNlcyBvbiB0aGUgc3Vi bmV0KS4NCg0KU3VyZSwgQkZEIHBlciBtZW1iZXIgd2lsbCB3b3JrIG9ubHkgb24gcG9pbnQtdG8t cG9pbnQgbGlua3MsIGJ1dCBldGhlciBpcyBzdGlsbCBjb25zaWRlcmVkIG11bHRpLWFjY2VzcyBt ZWRpYS4gU3VidGxlIGFuZCBtaW5vciwgeWVzLiBCdXQgbGVzcyBsaWtlbHkgdG8gZGV2aWF0ZSBp ZiB3ZSB1c2UgdW5pY2FzdCBJUCBhZGRyZXNzLg0KDQpTb21lIGFyZ3VtZW50cyBnaXZlbiBhZ2Fp bnN0IHVuaWNhc3QgSVAgYXBwcm9hY2ggaW4gdGhlIGRyYWZ0IGxhY2tzIHNvbWUgaW5mb3JtYXRp b24uIEZvciBleGFtcGxlLCBpZiB3ZWxsLWtub3duIE1BQyBpcyB1c2VkIHdpdGggdW5pY2FzdCBJ UCwgQVJQIHBvaW50IGlzIHJlYWxseSBub3QgdmFsaWQuIEFub3RoZXIgd2lsbCBiZSB0aGF0LCBk ZXN0aW5hdGlvbiBhZGRyZXNzIHJlcXVpcmVkLiBTaW1wbGljaXR5IGlzIGdvb2QsIGJ1dCBub2Jv ZHkgaGFzIGFyZ3VlZCBhZ2FpbnN0IHRoaXMgY29uZmlnIGFzIHRvbyBtdWNoL2NvbXBsaWNhdGVk LiBJZiB3ZSBjb25zaWRlciB0aG9zZSwgdGhlbiB1bmljYXN0IElQIGRvZXNuJ3QgbG9vayBzbyBi YWQuDQoNCkFuZCwgdGhlcmUncyBhbHNvIHRoZSBhc3BlY3Qgb2YsIGlmIHdlIHdlcmUgdG8gdXNl IHVuaWNhc3QgSVAsIHdoYXQgY2hhbmdlcyBhcmUgbmVlZGVkIHRvIHJ1biBCRkQgcGVyIG1lbWJl ciBhbmQgc2FtZSBBRiBCQlAgb24gbWFpbiA4MDIuMWF4IGludGVyZmFjZS4NCg0KRG9uJ3QgZ2V0 IG1lIHdyb25nLCBJJ20gbm90IGFnYWluc3QgbXVsdGljYXN0IElQIHVzYWdlIG9uIHRoaXMgdGVj aG5vbG9neSAoMWEpLCBidXQgdGhpbmdzIGhhdmUganVzdCBtb3ZlZCBzbyBmYXN0IHdpdGggdGhp cyBkcmFmdCAuLi4gSSdtIGp1c3QgY3JlYXRpbmcgc29tZSBub2lzZSB0byBzZWUgaWYgd2UgaGF2 ZSBleGhhdXN0ZWQgbmVjZXNzYXJ5IGRpc2N1c3Npb25zLg0KDQpJbiBhbnkgY2FzZSwgbXlzZWxm IGFuZCBmZXcgb3RoZXJzLCBpbmNsdWRpbmcgYWxsIE1NTSBhdXRob3JzLCBoYXZlIGJlZW4gZXhj aGFuZ2luZyBzb21lIGVtYWlscyBvdXRzaWRlIG9mIHRoZSBsaXN0LiBPbmUgb2YgdXMgc2hvdWxk IGJlIGFibGUgdG8gZ2V0IGJhY2sgd2l0aCBjb25jbHVzaW9uIHNvb24uDQoNClJlZ2FyZHMsDQpO b2JvDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogcnRnLWJmZC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhh bGYgT2YgVG9tIFNhbmRlcnMNCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIyLCAyMDExIDEw OjE3IEFNDQo+IFRvOiBKZWZmIFRhbnRzdXJhDQo+IENjOiBydGctYmZkQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBNdWx0aWNhc3QgdnMgVW5pY2FzdCAod2FzIEJGRCBvbiBMQUcgaW50ZXJmYWNl cykNCj4gDQo+IE9oIGFuZCBidHcsIGkgd291bGQgdG9vIHByZWZlciBvcHRpb24gKDFhKSwgaS5l LiBnb2luZyB0aGUgbXVsdGljYXN0IHdheS4NCj4gDQo+IFRvbXMNCj4gDQo+IE9uIDIyIERlY2Vt YmVyIDIwMTEgMDY6MjgsIEplZmYgVGFudHN1cmEgPGplZmYudGFudHN1cmFAZXJpY3Nzb24uY29t Pg0KPiB3cm90ZToNCj4gPiBIaSwNCj4gPg0KPiA+IC8qY3VzdG9tZXIvcHJvZHVjdCBtYW5hZ2Vy IG1vZGUqLw0KPiA+IElmIHdlIHNldCBhc2lkZSByZWxpZ2lvdXMgZGlzY3Vzc2lvbiBhYm91dCBs YXllciB2aW9sYXRpb24vZXRjIElNSE8NCj4gMWEgaXMganVzdCBmaW5lLCBpdCBhbGxvd3MgcmV1 c2luZyBleGlzdGluZyBCRkQgaW1wbGVtZW50YXRpb25zIHdpdGgNCj4gbWluaW11bSBjaGFuZ2Vz LCBoZW5jZSBkZWNyZWFzZXMgdGltZSB0byBtYXJrZXQgPT0gaGFwcHkgY3VzdG9tZXJzLg0KPiA+ IEkgdGhpbmsgd2Ugc2hvdWxkIHN0aWxsIGJlIGtlZXBpbmcgb3VyIGZvY3VzIG9uIElQIExBRywg YXMgd2UgYXJlIHRyeWluZw0KPiB0byBleHRlbmQgUkZDNTg4MSB0byB3b3JrIG92ZXIgTEFHIHdo ZXJlIEJGRCBpcyB1c2VkIGlzIHRvIHRyYWNrIElQdjQNCj4gYW5kIElQdjYgY29ubmVjdGl2aXR5 IGJldHdlZW4gZGlyZWN0bHkgY29ubmVjdGVkIHN5c3RlbXMNCj4gPiBJTU8gZm9yIEwyIExBRyBF dGggT0FNIHdvdWxkIG1ha2UgbXVjaCBtb3JlIHNlbnNlIChlZy4gLjFhZyBhd2FyZSBMQUcpLg0K PiA+DQo+ID4gUmVnYXJkcywNCj4gPiBKZWZmDQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogcnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgVG9tIFNhbmRlcnMNCj4g PiBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDIxLCAyMDExIDQ6MzEgUE0NCj4gPiBUbzogcnRn LWJmZEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IE11bHRpY2FzdCB2cyBVbmljYXN0ICh3YXMgQkZE IG9uIExBRyBpbnRlcmZhY2VzKQ0KPiA+DQo+ID4gVGhlIHR3byBvcHRpb25zIGJlZm9yZSB0aGUg V0cgYXJlOg0KPiA+DQo+ID4gMS4gVXNlIElQIGVuY2Fwc3VsYXRpb24NCj4gPiAyLiBVc2UgZGly ZWN0IEwyIGVuY2Fwc3VsYXRpb24uDQo+ID4NCj4gPiBXaXRoICgxKSB3ZSBoYXZlIGFuIG9wdGlv biBvZiAoMWEpIFVzaW5nIE11bHRpY2FzdCBhbmQgKDFiKSBVc2luZyBVbmljYXN0Lg0KPiA+DQo+ ID4gQ2FuIHdlIGFycml2ZSBvbiBhIGNvbnNlbnN1cyBiZXR3ZWVuIGNob29zaW5nIDFhIGFuZCAx Yj8NCj4gPg0KPiA+IEdpdmVuIHRoYXQgdGhlIG5ldyBkcmFmdCBoYXMgdGhpcyBuaWNlIEFwcGVu ZGl4IHRoYXQgc3VjY2luY3RseSBkaXNjdXNzZXMNCj4gdGhpcywgY2FuIHRoZSBwcm9wb25lbnRz IG9mICgxYikganVzdGlmeSB3aHkgdGhleSB0aGluayAoMWEpIGlzIG5vdCBnb29kDQo+IGVub3Vn aC4NCj4gPg0KPiA+IExldHMgdHJ5IGNsb3NpbmcgdGhlIGRpZmZlcmVudCB0aHJlYWRzIHNvIHRo YXQgd2UgY2FuIGNvbnZlcmdlIHRvd2FyZHMNCj4gYSBzb2x1dGlvbi4NCj4gPg0KPiA+IFRvbXMN Cj4gPg0KPiA+IE9uIDIwIERlY2VtYmVyIDIwMTEgMDY6MjQsIEdsZW4gS2VudCA8Z2xlbi5rZW50 QGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+IFNvbWUgbW9yZSByZWFzb25zIGZvciBnb2luZyBpbiBm b3IgbXVsdGljYXN0IGdpdmVuIGF0IHRoZSBlbmQgb2YgdGhlDQo+ID4+IG5ldyB2ZXJzaW9uLg0K PiA+Pg0KPiA+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tbW0tYmZkLW9uLWxh Z3MtMDEjYXBwZW5kaXgtQS4xDQo+ID4+DQo+ID4+IEkgZG9udCB0aGluayB0aGVyZSBpcyBhIG5l ZWQgdG8gc3BlY2lmeSB0aGF0IHRoZSBUVEw9MSBzaW5jZSB0aGUNCj4gPj4gbXVsdGljYXN0IGFk ZHJlc3NlcyBoYXZlIGEgbGluayBsb2NhbCBzY29wZS4gQW0gaSBtaXNzaW5nIHNvbWV0aGluZz8N Cj4gPj4NCj4gPj4gVGhhbmtzLA0KPiA+PiBHbGVuDQo+ID4+DQo+ID4+IE9uIFR1ZSwgRGVjIDIw LCAyMDExIGF0IDU6MDggQU0sIE1hcmMgQmluZGVyYmVyZ2VyIDxtYXJjQHNuaWZmLmRlPg0KPiB3 cm90ZToNCj4gPj4+IEhlbGxvIE5vYm8sDQo+ID4+Pg0KPiA+Pj4+IEkgc2VlIG5ldyByZXZpc2lv biBvdXQgdGhlcmUsIHdpbGwgaGF2ZSB0byBnbyBjaGVjayBpdCBvdXQuDQo+ID4+Pg0KPiA+Pj4g VGhhbmtzIGZvciB0aGUgaW50ZXJlc3QgOi0pDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiBUaGUgb3Ro ZXIgcXVlc3Rpb24gdGhhdCBJIGhhdmUgb24gdGhpcyBkcmFmdCBpcywgZG8gd2UgcmVhbGx5DQo+ ID4+Pj4gbmVlZC93YW50IHRvIHJlc2VydmUgSVAgbXVsdGljYXN0IGFkZHJlc3MgZm9yIHRoaXMg cHVycG9zZS4gTW9zdA0KPiA+Pj4+IGNhc2VzLCBpZiBub3QgYWxsLCB3aGVyZSBvcGVyYXRvciB3 YW50cyB0byB1c2UgQkZEIHRvIHByb3RlY3QgTEFHDQo+IGF0DQo+ID4+Pj4gbWVtYmVyIGxldmVs IHNob3VsZCBoYXZlIHNvbWUgc29ydCBvZiBJUCBhZGRyZXNzIGFzc2lnbmVkIGF0IExBRy4NCj4g Pj4+DQo+ID4+PiBJIGhhdmUgc2VlbiB0aGVyZSBoYWQgYmVlbiBzb21lICJ1bm51bWJlcmVkIiBk aXNjdXNzaW9uIGJ1dCBhY3R1YWxseQ0KPiB0aGF0IGlzIG5vdCB0aGUgcmVhc29uLiBBY3R1YWxs eSAidW5udW1iZXJlZCIgd2FzIHB1dCBhc2lkZSB3aGVuIHdlDQo+IGRpc2N1c3NlZCB0aGUgb3Jp Z2luYWwgZHJhZnQtY2hlbi1iZmQtaW50ZXJmYWNlIGFuZCB0aGUgbGlzdCBmZWVkYmFjaw0KPiB3 YXMgdG8gZm9jdXMgb24gTEFHIHdpdGggSVAgYXQgdGhhdCB0aW1lLg0KPiA+Pj4NCj4gPj4+DQo+ ID4+PiBXaGF0IHdlIHdhbnQgdG8gYWNoaWV2ZToNCj4gPj4+DQo+ID4+PiAtIHlvdSBjYW4gaGF2 ZSBhIG1lbWJlci1saW5rIHNlc3Npb24gKGFrYSAibWljcm8gc2Vzc2lvbiIpDQo+ID4+PiAtIHlv dSBjYW4gaGF2ZSBhZGRpdGlvbmFsbHkgYSBCQlAgc2Vzc2lvbiAodGhlIHNpbmdsZSBzZXNzaW9u IG92ZXINCj4gPj4+IExBRykgZm9yIHRoZSBtYWluIExBRyBpbnRlcmZhY2UNCj4gPj4+DQo+ID4+ PiBPbiB0aGUgcmVjZWl2aW5nIHNpZGUsIHdoYXQgZG8geW91IGRvIHRvIGRpZmZlcmVudGlhdGUg dGhlc2Ugc2Vzc2lvbnMNCj4gKHRoaW5rIGFib3V0IHRoZSB5b3VyX2Rpc2NyIHplcm8gY2FzZSk/ DQo+ID4+Pg0KPiA+Pj4gKGkpIGRpZmZlcmVudCBhZGRyZXNzDQo+ID4+PiAoaWkpIGRpZmZlcmVu dCBVRFAgcG9ydA0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBCb3RoIHNob3VsZCB3b3JrLiBXZSBzdGFy dGVkIHRoZSBkcmFmdCB3aXRoIChpKSBpbiBtaW5kIGFuZCBJIGRvbid0DQo+IHNlZSBhIGhhcmQg cmVhc29uIHRvIGNoYW5nZSB0aGlzLg0KPiA+Pj4NCj4gPj4+IEZvciAoaSkgeW91IHRoZW4gY29t ZSB1cCB3aXRoIHRoZSBpZGVhIG9mIGEgImRlZGljYXRlZCBhZGRyZXNzIi4gMTI3LzgNCj4gd2Fz IHByb3Bvc2VkIGJ5IEdyZWdvcnkgYW5kIGFnYWluLCB0aGF0IHdvdWxkIHdvcmsgYWx0aG91Z2gg Li4uIGhvdyBkbw0KPiB5b3UgZGlmZmVyZW50aWF0ZSB0aGlzIGZyb20gYSBCRkQtTFNQIChSRkZD NTg4NCkgcGFja2V0IGFycml2aW5nIG9uIHRoZQ0KPiBMQUcgaW50ZXJmYWNlPyDCoFNvIGEgTXVs dGljYXN0IGFkZHJlc3Mgc2VlbXMgYW5vdGhlciBvcHRpb24uDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ PiBSZXN1bHRpbmcgYmVoYXZpb3Igd2lsbCBiZSBsZXNzIGRldmlhdGluZyBmcm9tIFJGQzU4ODE6 IHNhbWUgZGVtdXgNCj4gPj4+PiBwcm9jZWR1cmVzIGNhbiBiZSB1c2VkIHdoZW4gZGlzY3JpbWlu YXRvciBpcyB6ZXJvKDApLA0KPiA+Pj4NCj4gPj4+IHNvIGNhbiBpdCBmb3IgdGhlIGxpbmstbG9j YWwgbXVsdGlob3AgYWRkcmVzcyBJIHRoaW5rIC0gbm8/IE5vdyB3ZQ0KPiBkbyBtZW50aW9uIHRo aXMgaW4gc2VjdGlvbiAzLjIsIGFzIGEgcmVtaW5kZXIgdGhhdCBmb3IgeW91cl9EaXNjciB6ZXJv DQo+IHRoZSBtYWluIGRpZmZlcmVuY2UgaXMgdGhlIGluZ3Jlc3MgaW50ZXJmYWNlOg0KPiA+Pj4N Cj4gPj4+IMKgIFRoZSBkZW11bHRpcGxleGluZyBvZiBhIHJlY2VpdmVkIHBhY2tldCBpcyBzb2xl bHkgYmFzZWQgb24gdGhlIFlvdXINCj4gPj4+IMKgIERpc2NyaW1pbmF0b3IgZmllbGQsIGlmIHRo aXMgZmllbGQgaXMgbm9uemVyby4gwqBGb3IgdGhlIGluaXRpYWwNCj4gPj4+IERvd24NCj4gPj4+ IMKgIHBhY2tldCBvZiBhIG1pY3JvIHNlc3Npb24gdGhpcyB2YWx1ZSBtYXkgYmUgemVyby4gwqBJ biB0aGlzIGNhc2UNCj4gPj4+IMKgIGRlbXVsdGlwbGV4aW5nIE1VU1QgYmUgYmFzZWQgb24gc29t ZSBjb21iaW5hdGlvbiBvZiBvdGhlciBmaWVsZHMNCj4gPj4+IMKgIHdoaWNoIE1VU1QgaW5jbHVk ZSB0aGUgaW50ZXJmYWNlIGluZm9ybWF0aW9uIG9mIHRoZSBtZW1iZXIgbGluay4NCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4+IG5vIG5lZWQgdG8NCj4gPj4+PiBjb21lIHVwIHdpdGggc3BlY2lhbCBjYXNl IG9mIFRUTD0xIHdoaWNoIHdhcyBkaXNjdXNzZWQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IG9oLW9o IEkgbWlzc2VkIHRoaXMgcGFydCEgSGF2ZSB0byBnbyB0aHJvdWdoIHRoZSBlbWFpbHMuIFRUTCA9 IDEgPyE/DQo+ID4+PiBPdXIgZHJhZnQgaXMgbm90IHRhbGtpbmcgYWJvdXQgdGhpcyAoc2VjdGlv biAzIG1lbnRpb25zIFJGQzU4ODAsIHNvDQo+ID4+PiB5b3Ugd291bGQgaGF2ZSBhIFRUTCBvZiAy NTUpDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiBJJ20gcXVlc3Rpb25pbmcNCj4gPj4+PiB0aGlzIGFz cGVjdCBzaW5jZSBJIGRpZG4ndCBzZWUgYW55IHN0cm9uZyBhcmd1bWVudHMgZm9yIGJ1cm5pbmcg dXANCj4gPj4+PiBJUCBtdWx0aWNhc3QgYWRkcmVzcy4NCj4gPj4+DQo+ID4+PiBhY3R1YWxseSBJ IHdvbmRlciBpZiBhbGwtcm91dGVyIG9yIGFsbC1ob3N0cyB3b3VsZG4ndCBkbyB0aGUgam9iLg0K PiBXZSBjb3VsZCBwcm9iYWJseSBldmVuIHVzZSAyNTUuMjU1LjI1NS4yNTUgYXMgdGhlIHNldHVw IGlzIGEgZGlyZWN0IGxpbmssDQo+IGJhY2sgdG8gYmFjay4gT3BlbiB0byB0aGlzLiBCdXQgaWYg aXQgdHVybnMgb3V0IHdlIG5lZWQgb25lLCB3ZWxsIHRoZW4NCj4gd2UgbmVlZCBvbmUuIE9yIGFs dGVybmF0aXZlbHkgLSBzZWUgKGlpKSBhYm92ZSAtIGEgbmV3IElBTkEgVURQIHBvcnQuDQo+IE5v dCBzdXJlIHdoYXQgaXMgYmV0dGVyL3dvcnNlLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBSZWdhcmRz LCBNYXJjDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+DQo+ID4+Pj4gVGhhbngs DQo+ID4+Pj4gTm9ibw0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+Pj4+IEZyb206IE1hcmMgQmluZGVyYmVyZ2VyIFttYWlsdG86bWFyY0BzbmlmZi5kZV0N Cj4gPj4+Pj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAxOSwgMjAxMSA1OjMzIFBNDQo+ID4+Pj4+ IFRvOiBOb2JvIEFraXlhIChub2JvKQ0KPiA+Pj4+PiBDYzogQWxleGFuZGVyIFZhaW5zaHRlaW47 IERhdmUgS2F0ejsgcnRnLWJmZEBpZXRmLm9yZw0KPiA+Pj4+PiBTdWJqZWN0OiBSZTogQkZEIG9u IExBRyBpbnRlcmZhY2VzDQo+ID4+Pj4+DQo+ID4+Pj4+IEhlbGxvIE5vYm8sDQo+ID4+Pj4+DQo+ ID4+Pj4+IHRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBMZXQgbWUgY2hlY2sgdGhpcyB3aXRoIHRo ZSBuZXcgdmVyc2lvbg0KPiB3ZQ0KPiA+Pj4+PiBhcmUganVzdCBwcmVwYXJpbmcgKGFsbW9zdCBk b25lKS4NCj4gPj4+Pj4NCj4gPj4+Pj4gQW5kIHllcywgYSBjbGVhbmVyIGRlc2NyaXB0aW9uIHdo ZW4gdGhlIGNyZWF0aW9uL2RlbGV0aW9uIGlzIHBhcnQNCj4gPj4+Pj4gb2YNCj4gPj4+PiBpdC4N Cj4gPj4+Pj4gQnV0IEkgYWxzbyB0aGluayB0aGlzIGlzIHdoZXJlIEFsZXhhbmRlcidzIGNvbW1l bnQgY2FtZSBmcm9tOg0KPiA+Pj4+PiB3aXRob3V0IHNvbWUgbW9kaWZpY2F0aW9ucyBpbiA4MDIu MUFYIGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIHRvDQo+ID4+Pj4+IGxvY2sgdGhlDQo+ID4+Pj4g ImdvaW5nDQo+ID4+Pj4+IFVQIiB3aXRoIEJGRC4gT3RoZXJ3aXNlIHlvdSBhbHdheXMgcnVuIGlu dG8gcXVlc3Rpb25zIGFuZCBpc3N1ZXMNCj4gLQ0KPiA+Pj4+IHN0YXJ0aW5nDQo+ID4+Pj4+IExB Q1AgZmlyc3Q/IE9yIEJGRCBmaXJzdD8gT3IgYm90aCBpbiBwYXJhbGxlbD8NCj4gPj4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pj4+IEdlbmVyYWxseSBzcGVha2luZywgd2hlbiB1cC9kb3duIHVzZSBkaWZm ZXJlbnQgbWV0aG9kcywgSSd2ZSBzZWVuDQo+ID4+Pj4+PiBhIHN5c3RlbSBmYWxsIGludG8gY29u dGludW91cyBmbGFwIGN5Y2xlLiBEb3duIGJ5IEJGRCwgdXAgYnkNCj4gPj4+PiBwcm90b2NvbC9M TU0NCj4gPj4+Pj4+IGlzIG9uZSBwb3NzaWJsZSBhcHByb2FjaCwgYW5kIHlvdXIgZHJhZnQgd2Fu dHMgdG8gYWxsb3cgdGhpcyBmb3INCj4gPj4+Pj4+IGludGVyb3BlcmFiaWxpdHkgcHVycG9zZS4g SSBjYW4gdW5kZXJzdGFuZCB0aGUgbmVlZCwgYnV0IHNpZGUNCj4gPj4+Pj4+IGVmZmVjdA0KPiA+ Pj4+PiBjYW4NCj4gPj4+Pj4+IGJlIG5hc3R5LCBhbmQgaXQgKHBvc3NpYmxlIGNvbnRpbnVvdXMg ZmxhcCkgY2FuIGJlIGRlc2NyaWJlZD8NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gKnNpZ2gq IHllcyAuLi4gbWF5YmUgd2Ugc2hvdWxkIHdyaXRlIGEgZHJhZnQgb24gZmxhcCBkYW1wZW5pbmc/ IDotKQ0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBMZXQgbWUgZ28gdGhyb3VnaCBvdXIgbGF0 ZXN0IChpbnRlcm5hbCkgdmVyc2lvbiBpZiB0aGF0IGFkZHJlc3Nlcw0KPiA+Pj4+PiB5b3VyIHBv aW50cy4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gVGhhbmtzIQ0KPiA+Pj4+Pg0KPiA+Pj4+ PiBSRWdhcmRzLCBNYXJjDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+ Pj4+IE9uIDIwMTEtMTItMTksIGF0IDI6NTkgLCBOb2JvIEFraXlhIChub2JvKSB3cm90ZToNCj4g Pj4+Pj4NCj4gPj4+Pj4+IEhlbGxvLA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFNlY3Rpb24gMy4yLg0K PiA+Pj4+Pj4NCj4gPj4+Pj4+PiBBIG1lbWJlciBsaW5rIG9mIHRoZSBMQUcgaXMgbm90IHVzZWQg YW55bW9yZSBmb3IgZGF0YSBmb3J3YXJkaW5nDQo+ID4+Pj4+PiB3aGVuDQo+ID4+Pj4+Pj4gdGhl IHBhcnRpY3VsYXIgQkZEIHNlc3Npb24gcnVubmluZyBvdmVyIHRoYXQgbGluayBnb2VzIGRvd24u IMKgVGhlDQo+ID4+Pj4+Pj4gbWVtYmVyIGxpbmsgTVVTVCBiZSByZW1vdmVkIGZyb20gdGhlIExB Ry4gwqBUaGUgQkZEIHNlc3Npb24gZm9yDQo+ID4+Pj4+Pj4gdGhlIGxpbmsgcmVtYWlucywgaS5l LiBpdCBpcyBub3QgZGVsZXRlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJdCBpcyBub3QgY2xlYXIg d2hlbiBCRkQgc2Vzc2lvbiBzaG91bGQgZ2V0IGRlbGV0ZWQgKG5vciBjcmVhdGVkKS4NCj4gPj4+ PiBXaXRoDQo+ID4+Pj4+PiBhYm92ZSBzdGF0ZW1lbnQsIEJGRCBzZXNzaW9uIGNvdWxkIHJlbWFp biBldmVuIHdoZW4gb3BlcmF0b3INCj4gPj4+Pj4+IGRlY2lkZXMNCj4gPj4+Pj4gdG8NCj4gPj4+ Pj4+IHNodXQgZG93biBhIG1lbWJlciwgZGVwZW5kaW5nIG9uIGhvdyBpdCdzIGludGVycHJldGVk L2ltcGxlbWVudGVkLg0KPiA+Pj4+IFdoZW4NCj4gPj4+Pj4+IExBQ1AgaXMgdXNlZCwgTE1NIHdp bGwgc3RhcnR1cCBMQUNQIG9ubHkgd2hlbiBpbnRlcmZhY2UgaXMgdXAuDQo+IEwyDQo+ID4+Pj4g Y2hlY2sNCj4gPj4+Pj4+IHN0YXJ0cyBvbmx5IHdoZW4gTDEgY2hlY2sgcGFzc2VzLiBDaGVjayBp cyBkb25lIGZyb20gYm90dG9tIGxheWVyDQo+ID4+Pj4+PiB1cHdhcmRzLiBHb2luZyBieSBzYW1l IGlkZWEsIEJGRCBzZXNzaW9uIHNob3VsZCBvbmx5IGJlIGNyZWF0ZWQNCj4gPj4+Pj4+IHdoZW4N Cj4gPj4+Pj4gTDINCj4gPj4+Pj4+IGNoZWNrIHBhc3NlcyAoTEFDUCksIHdoZW4gTDIgY2hlY2sg aXMgYmVpbmcgdXNlZC4gSWYgTDIgY2hlY2sgaXMNCj4gPj4+Pj4+IG5vdCBiZWluZyB1c2VkLCB0 aGVuIEwxIGNoZWNrIGlzIHJlcXVpcmVkIGZvciBCRkQgc2Vzc2lvbiB0byBnZXQNCj4gPj4+PiBj cmVhdGVkLg0KPiA+Pj4+Pj4gQWJzZW5jZSBpbiBMMS9MMiBjaGVjayBwYXNzIHNob3VsZCBjYXVz ZSBjb3JyZXNwb25kaW5nIEJGRA0KPiA+Pj4+Pj4gc2Vzc2lvbnMNCj4gPj4+Pj4gdG8NCj4gPj4+ Pj4+IGdldCBkZWxldGVkLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4+IDMuIFRoZSBz aXR1YXRpb24gd2hlbiBMQUcgZ29lcyBkb3duIGR1ZSB0byBpbnN1ZmZpY2llbnQgbnVtYmVyDQo+ ID4+Pj4+Pj4+IG9mDQo+ID4+Pj4+PiBhY3RpdmUNCj4gPj4+Pj4+PiBsaW5rcyBtdXN0IGJlIHJl dmVyc2libGUsIGkuZS4sIHRoZSBMQUcgbXVzdCBiZSBhYmxlIHRvIGdvIFVQDQo+ID4+Pj4+Pj4g b25jZQ0KPiA+Pj4+Pj4gdGhpcw0KPiA+Pj4+Pj4+IGNvbmRpdGlvbiBkaXNhcHBlYXJzLg0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4geWVzLCBJIHdvdWxkIHByZWZlciB0aGlzIDstKQ0KPiA+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+IERvIHRoZXNlIG5vdGVzIGNhcHR1cmUgdGhlIHByb2JsZW0gc3BhY2UgY29y cmVjdGx5PyBPciBkaWQgSQ0KPiA+Pj4+Pj4+PiBtaXNzDQo+ID4+Pj4+Pj4gc29tZXRoaW5nIGlt cG9ydGFudD8NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gT25lIHBvaW50IHRoYXQgaXMgbm90IGNs ZWFyIHRvIG1lIGlzIHRoZSB0aW1lZnJhbWUgZm9yIGJyaW5naW5nDQo+ID4+Pj4+Pj4gY29uc3Rp dHVlbnQgbGlua3Mgb2YgYSBMQUcgdXAuIEkgd291bGQgZXhwZWN0IHRoYXQgdGhlDQo+ID4+Pj4+ Pj4gcmVxdWlyZW1lbnRzDQo+ID4+Pj4+PiBmb3INCj4gPj4+Pj4+PiB0aGF0IGNvdWxkIGJlIG11 Y2ggbW9yZSByZWxheGVkIChlLmcuLCBpbiBvcmRlciB0byBhdm9pZCBsaW5rDQo+ID4+Pj4+PiBm bGFwcGluZykuDQo+ID4+Pj4+Pj4gSXMgdGhhdCBjb3JyZWN0PyBJZiBpdCBpcywgb25lIHBvc3Np YmxlIGltcGxpY2F0aW9uIGlzIHRoYXQgaXQNCj4gaXMNCj4gPj4+Pj4+IHBvc3NpYmxlDQo+ID4+ Pj4+Pj4gdG8gdXNlIGRpZmZlcmVudCBtZWNoYW5pc21zIGZvciBicmluZ2luZyBsaW5rcyBET1dO IGFuZCBVUC4gVG8NCj4gPj4+Pj4+PiB0aGUNCj4gPj4+Pj4+IGJlc3QNCj4gPj4+Pj4+PiBvZiBt eSB1bmRlcnN0YW5kaW5nLCB0aGlzIGlzIGhvdyBCRkQgaXMgc3VwcG9zZWQgdG8gYmUgdXNlZCB3 aXRoDQo+ID4+Pj4+PiByb3V0aW5nDQo+ID4+Pj4+Pj4gYWRqYWNlbmNpZXMgdG9kYXksIGkuZS4g QkZEIGNhbiBicmluZyB0aGUgYWRqYWNlbmN5IERPV04gcXVpdGUNCj4gPj4+PiBmYXN0LA0KPiA+ Pj4+Pj4gYnV0DQo+ID4+Pj4+Pj4gaXQgaGFzIHRvIGJlIGJyb3VnaHQgVVAgYnkgdGhlIGFwcHJv cHJpYXRlIHJvdXRpbmcgcHJvdG9jb2wuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiB0aGUgZHJhZnQg YWxsb3dzIHRoaXMsIHNlY3Rpb24gMy4yICJUbyBhdm9pZCB0aGlzIGRlYWRsb2NrIC4uLiIuDQo+ ID4+Pj4+Pj4gU28NCj4gPj4+Pj4+IHVzaW5nDQo+ID4+Pj4+Pj4gQkZEIHRvIGJyaW5nIGRvd24g ZmFzdCBhbG9uZSBpcyBjb3ZlcmVkLiBOb3cgUkZDNTg4MiwgZS5nLg0KPiA+Pj4+Pj4+IHNlY3Rp b24NCj4gPj4+Pj4+IDQuMSwNCj4gPj4+Pj4+PiBtZW50aW9ucyB0aGF0IHdhaXRpbmcgZm9yIEJG RCdzIFVwIG5vdGlmaWNhdGlvbiBtYXkgYmUgdXNlZnVsLg0KPiA+Pj4+Pj4+IFRodXMNCj4gPj4+ Pj4gd2UNCj4gPj4+Pj4+PiBhbGxvd2VkIHRoaXMgaW4gdGhlIGRyYWZ0IGFzIHdlbGwuDQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFtJIHNraXAgdGhlIExBQ1AsIENGTSBwYXJ0LiBX ZSBoYWQgdGhpcy4gTm90aGluZyB3cm9uZw0KPiA+Pj4+Pj4+IHRlY2huaWNhbGx5DQo+ID4+Pj4+ IGJ1dA0KPiA+Pj4+Pj4+IHNvbWVob3cgY3VzdG9tZXJzIHB1c2ggQkZEIHRlYW1zIHRvIGRlbGl2 ZXJdDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gR2VuZXJhbGx5IHNwZWFraW5nLCB3aGVuIHVwL2Rvd24g dXNlIGRpZmZlcmVudCBtZXRob2RzLCBJJ3ZlIHNlZW4NCj4gPj4+Pj4+IGEgc3lzdGVtIGZhbGwg aW50byBjb250aW51b3VzIGZsYXAgY3ljbGUuIERvd24gYnkgQkZELCB1cCBieQ0KPiA+Pj4+IHBy b3RvY29sL0xNTQ0KPiA+Pj4+Pj4gaXMgb25lIHBvc3NpYmxlIGFwcHJvYWNoLCBhbmQgeW91ciBk cmFmdCB3YW50cyB0byBhbGxvdyB0aGlzIGZvcg0KPiA+Pj4+Pj4gaW50ZXJvcGVyYWJpbGl0eSBw dXJwb3NlLiBJIGNhbiB1bmRlcnN0YW5kIHRoZSBuZWVkLCBidXQgc2lkZQ0KPiA+Pj4+Pj4gZWZm ZWN0DQo+ID4+Pj4+IGNhbg0KPiA+Pj4+Pj4gYmUgbmFzdHksIGFuZCBpdCAocG9zc2libGUgY29u dGludW91cyBmbGFwKSBjYW4gYmUgZGVzY3JpYmVkPw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBTZWN0aW9uIDQsIGZpcnN0IGJ1bGxldC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBMQUcgd2ls bCBiZSB0YWtlbiBkb3duIHdoZW4gQkZEIGZhaWxzIG9uIHN1ZmZpY2llbnQgbWVtYmVycyAoTEFH DQo+ID4+Pj4+PiBpbnRlcmZhY2Ugc3RhdGUgd2lsbCBiZSBkb3duKS4gTEFHIHdpbGwgY29tZSB1 cCBwb3RlbnRpYWxseSB3aGVuDQo+ID4+Pj4+PiBCRkQNCj4gPj4+Pj4gb24NCj4gPj4+Pj4+IHN1 ZmZpY2llbnQgbWVtYmVycyBjb21lIHVwIChMQUcgaW50ZXJmYWNlIHN0YXRlIHdpbGwgYmUgdXAp LiBUaGlzDQo+ID4+Pj4+PiBiZWhhdmlvciBpbXBsaWVzIHRoYXQgYWxsIGFwcGxpY2F0aW9ucyB3 aWxsIGJlbmVmaXQgKGJ5IG1vbml0b3JpbmcNCj4gPj4+PiBMQUcNCj4gPj4+Pj4+IGludGVyZmFj ZSBzdGF0ZSkgZXZlbiBpZiB0aG9zZSBhcHBsaWNhdGlvbnMgZG8gbm90IGNvbmZpZ3VyZSBCRkQN Cj4gPj4+Pj4+IG9uDQo+ID4+Pj4+IExBRy4NCj4gPj4+Pj4+IFN1cmUsIG9uZSBjYW4gY29uZmln dXJlIGFwcGxpY2F0aW9ucyB3aXRoIEJGRCBvdmVyIExBRywgYnV0IHRoYXQncw0KPiA+Pj4+IG5v dA0KPiA+Pj4+Pj4gYW4gYWJzb2x1dGUgcmVxdWlyZW1lbnQgZm9yIHRoaXMgbW9kZWwuIFN0YXRl bWVudHMgcmVnYXJkaW5nIHRoaXMNCj4gPj4+Pj4+IGJlaGF2aW9yIHdpbGwgYmUgYmVuZWZpY2lh bCB0byByZWFkZXJzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoYW54LA0KPiA+Pj4+Pj4gTm9ibw0K PiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gLS0NCj4gPj4+Pj4gTWFyYyBCaW5kZXJiZXJnZXIg wqAgwqAgwqAgwqAgwqAgPG1hcmNAc25pZmYuZGU+DQo+ID4+Pj4NCj4gPj4+DQo+ID4+PiAtLQ0K PiA+Pj4gTWFyYyBCaW5kZXJiZXJnZXIgwqAgwqAgwqAgwqAgwqAgPG1hcmNAc25pZmYuZGU+DQo+ ID4+Pg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gVG9tcy4NCj4gDQo+IA0KPiANCj4gLS0N Cj4gVG9tcy4NCg== From manav.bhatia@alcatel-lucent.com Thu Dec 22 07:55:48 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 CAE0421F8AFB for ; Thu, 22 Dec 2011 07:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTZwBsYAC7qf for ; Thu, 22 Dec 2011 07:55:47 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id C814521F8AF8 for ; Thu, 22 Dec 2011 07:55:47 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBMFtenQ012662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Dec 2011 09:55:43 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBMFtd11017073 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 22 Dec 2011 21:25:39 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 22 Dec 2011 21:25:39 +0530 From: "Bhatia, Manav (Manav)" To: "Nobo Akiya (nobo)" , Tom Sanders , Jeff Tantsura Date: Thu, 22 Dec 2011 21:25:37 +0530 Subject: RE: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Topic: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Index: AczAR2ZYRcWugDMCSHGEYjQ1ryTh2wAbeB5gAAFv4FA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BA9A3@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <0ED867EB33AB2B45AAB470D5A64CDBF6181C5694C2@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:55:48 -0000 >=20 > We will have minor differences with RFC5881 when we start=20 > using multicast address. >=20 > For example: >=20 > On a multiaccess network, BFD Control packets MUST be transmitted > with source and destination addresses that are part of the subnet > (addressed from and to interfaces on the subnet). I am not sure if quoting 5881 really helps here, since 5881 also states: BFD Control packets MUST be transmitted in UDP packets with destination port 3784, within an IPv4 or IPv6 packet.=20 For Unicast we're thinking of using a different UDP port, so a violation is= done there as well. Also note that we may, at some point of time, start supporting BFD for mult= ipoint networks. In that case, we may end up receiving BFD packets with a m= ulticast destination IP. [snipped] =20 > Some arguments given against unicast IP approach in the draft=20 > lacks some information. For example, if well-known MAC is=20 > used with unicast IP, ARP point is really not valid. Another=20 In my private email I had pointed out that this is an unnatural design. Using a well known L2 multicast MAC address for unicast L3 is quite kludgy.= Router Implementations look at the dest MAC and if it's the system's or th= e port's MAC or an L3 multicast MAC then those packets are sent to the L3 e= ngine. Packets with any other MAC (IS-IS is an exception) are considered fo= r L2 switching. Now, by introducing well known MACs that L3 can use we star= t complicating the HW by introducing a list of special MACs (besides IS-IS)= that now need to be processed by L3. Doing it for micro sessions is settin= g up a bad precedent. One day we'll find that we have a list of 50+ special= MACs that L3 needs to process. >From system scaling, this is not good. Its architecturally a hack.=20 Currently we have instances where we use a multicast IP address for Unicast= purposes (Sections 8.1 and 8.2 of RFC 2328) [snipped] >=20 > In any case, myself and few others, including all MMM=20 > authors, have been exchanging some emails outside of the=20 > list. One of us should be able to get back with conclusion soon. Yup, and this should happen very soon! Cheers, Manav= From nitinb@juniper.net Thu Dec 22 11:37:36 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 C89D821F893C for ; Thu, 22 Dec 2011 11:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpcH7PTeowSG for ; Thu, 22 Dec 2011 11:37:36 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 234F321F891D for ; Thu, 22 Dec 2011 11:37:36 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTvOG+xwOyPW/j7z3FGteHCxpP71wENGX@postini.com; Thu, 22 Dec 2011 11:37:36 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 22 Dec 2011 11:34:55 -0800 From: Nitin Bahadur To: "Bhatia, Manav (Manav)" , Jeff Tantsura , "rtg-bfd@ietf.org" Date: Thu, 22 Dec 2011 11:34:53 -0800 Subject: Re: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nAAIeguvwABXIygAZefe2g= Message-ID: In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D026F0FFC@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 22 Dec 2011 19:37:36 -0000 Hi Manav, > Using the IP address of the interface leads into a cyclic loop as you can= t bring up the member links since L3 is not up, and > you cant bring up L3 since the member links are still down. I think we are talking of 2 different things here. In vanilla BFD mode toda= y, the IP link comes up first and then BFD starts on it. BFD in no way brings down a Sonet link for instance. So why do you want BFD to bring down= an Ethernet link? If you want that to happen, you have to use L2 encap or use ethernet oam. If all member links are down, then the AE will be down and L3 will be down = as well. Once a single AE member comes up, the AE bundle should come up. Once the AE is UP, your ARP will work as well and L3 will come UP.= And then your BFD on that AE member will come as well. Now that BFD is UP, you can feed that into routing protocols or other proto= cols that can feed off that. When the 2nd AE member comes up, the 2nd BFD session will also come up. And you can feed that again into whatever protoc= ol you want. Note that "you can bring the member link UP even when L3 is not up". The me= mber link just comes up itself....maybe I am missing something very basic h= ere. > On a point-to-point link isn't the discriminator value good enough to che= ck if the packet is indeed for the recipient? On a p2p link yes....but you are assuming that the P2P link doesn'= t have any L2 switches in the middle. If there are L2 switches in the middl= e, you could have mis-routed packets coming in and in that case the disc= riminator value is not sufficient. Thanks Nitin From nitinb@juniper.net Thu Dec 22 12:01:04 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 458861F0C36 for ; Thu, 22 Dec 2011 12:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tzu3faF7pbx3 for ; Thu, 22 Dec 2011 12:01:03 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id A93D421F858D for ; Thu, 22 Dec 2011 12:00:59 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTvOMeNwi9J9kkNYTGQy4+KY09CMUPztf@postini.com; Thu, 22 Dec 2011 12:00:59 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 22 Dec 2011 11:58:54 -0800 From: Nitin Bahadur To: Nitin Bahadur , "Bhatia, Manav (Manav)" , Jeff Tantsura , "rtg-bfd@ietf.org" Date: Thu, 22 Dec 2011 11:58:51 -0800 Subject: Re: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nAAIeguvwABXIygAZefe2gAANZHOg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-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, 22 Dec 2011 20:01:04 -0000 And just to clarify a little bit more.... I don't want BFD to replace LACP. I want it to supplement LACP. Just like t= oday if we run BFD for OSPF adjacencies, we don't get rid of OSPF hellos... But if the BFD session goes down, we tell OSPF about it and OSPF reacts to = that. Similarly (pardon my lack of knowledge about LACP), LACP can react to BFD member sessions down. The link can be brought up by LACP at a slower in= terval. The goal should be fast failure detection and not necessarily fast Link-up following a failure correction. Thanks Nitin On 12/22/11 11:34 AM, "Nitin Bahadur" wrote: Hi Manav, > Using the IP address of the interface leads into a cyclic loop as you can= t bring up the member links since L3 is not up, and > you cant bring up L3 since the member links are still down. I think we are talking of 2 different things here. In vanilla BFD mode toda= y, the IP link comes up first and then BFD starts on it. BFD in no way brings down a Sonet link for instance. So why do you want BFD to bring down= an Ethernet link? If you want that to happen, you have to use L2 encap or use ethernet oam. If all member links are down, then the AE will be down and L3 will be down = as well. Once a single AE member comes up, the AE bundle should come up. Once the AE is UP, your ARP will work as well and L3 will come UP.= And then your BFD on that AE member will come as well. Now that BFD is UP, you can feed that into routing protocols or other proto= cols that can feed off that. When the 2nd AE member comes up, the 2nd BFD session will also come up. And you can feed that again into whatever protoc= ol you want. Note that "you can bring the member link UP even when L3 is not up". The me= mber link just comes up itself....maybe I am missing something very basic h= ere. > On a point-to-point link isn't the discriminator value good enough to che= ck if the packet is indeed for the recipient? On a p2p link yes....but you are assuming that the P2P link doesn'= t have any L2 switches in the middle. If there are L2 switches in the middl= e, you could have mis-routed packets coming in and in that case the disc= riminator value is not sufficient. Thanks Nitin From marc@sniff.de Thu Dec 22 13:57:15 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 ED0861F0C4A for ; Thu, 22 Dec 2011 13:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omYTBqS1Qr2m for ; Thu, 22 Dec 2011 13:57:15 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A07EC1F0C35 for ; Thu, 22 Dec 2011 13:57:14 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id E2CD72AA0F; Thu, 22 Dec 2011 21:57:11 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Thu, 22 Dec 2011 22:57:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6D4CAC2E-DBAE-43C1-A101-28EF5652CA18@sniff.de> References: To: Nitin Bahadur 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: Thu, 22 Dec 2011 21:57:16 -0000 Hello Nitin, I do not disagree but the goal you define may be too restricted. > The goal should be fast failure detection We should all be able to agree on this. This is the minimum achievement. But already this goal may have two options: with and without LACP. While = I would recommend LACP to customers it does not mean it's always = possible. Without LACP you likely want to prevent a LAG link "going up" after you = just received a BFD Down state. But how? Even with LACP you could - maybe not a very likely scenario - have LACP = connectivity but BFD is interrupted. Again stopping an immediate link = "going up" again may be a good thing. For now I prefer an L3 encaps that is not preventing BFD to control the = "going up". We may drop it when we learn the solution covering, lets = say, 90% of the setups (LACP supported by BFD down?) is small & elegant = while the 100% solution is a complex beast. But we don't know this yet. And of course we don't know if - for a standardization - it is possible = to define a packet Rx/Tx API at layer-3. Another reason why I think = after a good discussion about pros and cons of Unicast, Multicast, new = UDP port we should stop that discussion and wait for the outcome of = other discussions, e.g. interaction between BFD and 802.1X state = machine. (still waiting for Dave Katz to shed some light on the "private API" = comment he made :-) For the "switch in the middle", maybe this wasn't clear but draft-mmm is = not supporting this for the per-member BFD. Nor do I think any other = draft I'm aware of. It's back-to-back. More precise: the per-member = sessions and the overall "BLM" is between directly connected neighbours, = as mentioned in RFC5882, section 7.3. This is why we allow a combination = of it with "BBP" (single session over LAG), as the single session can go = through an Ethernet switch; this is scenario 7.4 in RFC5882. I assume you mention the switch to explain why the per-interface IP = address is a good thing, as it allows a check if the BFD packet arrived = at the right interface? Now for LAG we have N ports and all the BFD = packets arriving will have the same destination IP address if you use = the interface IP; I think this IP check must be dropped for micro = sessions. Instead the "interface information" must be used. Or some out-of-band = mechanism informs you about the remove discriminator, similar to RFC5884 = (I'm not promoting this, I don't like it too much due to the complexity = but for the sake of a more complete discussion I mention it) "Interface information" is another interesting point for the Rx/Tx API = in the standard. Can we demand this information for a layer-3 API? (not asking if we code-wise can do it. We probably all _do_ already). Too long, my email. In short: I don't think we can get to a conclusion = about Unicast/Multicast until we have discussed the other topics and = then see what is needed. Regards, Marc On 2011-12-22, at 20:58 , Nitin Bahadur wrote: >=20 > And just to clarify a little bit more.... >=20 > I don't want BFD to replace LACP. I want it to supplement LACP. Just = like today if we run BFD for OSPF adjacencies, we don't get rid of OSPF = hellos... > But if the BFD session goes down, we tell OSPF about it and OSPF = reacts to that. Similarly (pardon my lack of knowledge about LACP), LACP = can react to > BFD member sessions down. The link can be brought up by LACP at a = slower interval. The goal should be fast failure detection and not = necessarily fast > Link-up following a failure correction. >=20 > Thanks > Nitin >=20 > On 12/22/11 11:34 AM, "Nitin Bahadur" wrote: >=20 > Hi Manav, >=20 >> Using the IP address of the interface leads into a cyclic loop as you = cant bring up the member links since L3 is not up, and >> you cant bring up L3 since the member links are still down. >=20 > I think we are talking of 2 different things here. In vanilla BFD mode = today, the IP link comes up first and then BFD starts on it. BFD in no = way > brings down a Sonet link for instance. So why do you want BFD to bring = down an Ethernet link? If you want that to happen, you have to use L2 = encap > or use ethernet oam. >=20 > If all member links are down, then the AE will be down and L3 will be = down as well. Once a single AE member comes up, the AE bundle should > come up. Once the AE is UP, your ARP will work as well and L3 will = come UP. And then your BFD on that AE member will come as well. > Now that BFD is UP, you can feed that into routing protocols or other = protocols that can feed off that. When the 2nd AE member comes up, the = 2nd BFD > session will also come up. And you can feed that again into whatever = protocol you want. >=20 > Note that "you can bring the member link UP even when L3 is not up". = The member link just comes up itself....maybe I am missing something = very basic here. >=20 >> On a point-to-point link isn't the discriminator value good enough to = check if the packet is indeed for the recipient? >=20 > On a p2p link yes....but you are assuming that the P2P link = doesn't have any L2 switches in the middle. If there are L2 switches in = the middle, you > could have mis-routed packets coming in and in that case the = discriminator value is not sufficient. >=20 > Thanks > Nitin >=20 -- Marc Binderberger From gregory.mirsky@ericsson.com Thu Dec 22 18:28: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 BCBCC11E80BA for ; Thu, 22 Dec 2011 18:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUW03FLeYFu1 for ; Thu, 22 Dec 2011 18:28:50 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0111E8081 for ; Thu, 22 Dec 2011 18:28:50 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBN2Sh3i010850; Thu, 22 Dec 2011 20:28:44 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 22 Dec 2011 21:28:38 -0500 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" Date: Thu, 22 Dec 2011 21:28:37 -0500 Subject: RE: BFDoLAGs Updated Thread-Topic: BFDoLAGs Updated Thread-Index: Acy+OS9qxsaIYupkSrqnyorVoAJcZQACedxgALXJNcA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 02:28:51 -0000 Dear Authors, et al., Please find my comments to the -01 version below: * Section 2.1, second para. I strongly disagree that IETF needs to standard= ize what is referred as "BFD over Big Pipe". I think it is more useful to t= ake this discussion into Informational document where different implementat= ions can be described and recommendations to interoperate provided. * Section 3.3 If standardization of the evaluation function put outside of = the scope of the document then role of the Concluded BFD state is out of sc= ope as well (second bullet in Section 4). * Section 7 considering discussion in Appendix A.1 I think that suggestion = that request for link-local multicast IP addresses will be made is prematur= e. * A.1 One of advantages of Unicast IP address, I suggest use of 127/8 range= , used as destination IP address for IP/UDP encapsulation of control packet= s for micro-BFD is that each micro-BFD session might be assigned unique des= tination IP address. And I don't see any of listed disadvantages playing an= y role if destination IP address selected from 127/8 range. * A.2 Use of Ethernet multicast address can be suggested if operator is cer= tain that LAG member is p2p in L2 sense. Otherwise, unicast Ethernet addres= s should be used.=20 Thank you for your kind consideration. Regards, Greg=20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Alexander Vainshtein Sent: Monday, December 19, 2011 4:21 AM To: Bhatia, Manav (Manav) Cc: rtg-bfd@ietf.org Subject: RE: BFDoLAGs Updated Manav, and all, I've looked up the -01 version of the draft. It seems to address some of my= earlier concerns (mainly dealing with various possible encapsulations) but= , IMHO, still leaves the critical architectural issues unresolved. Please consider the following scenario: A LAG comprises N potential member links but limits the number of concurren= tly active links to M < N. Priorities of the links are exchanged via LACP (which also guarantees that = all the potential links have been, indeed, associated with the same LAG by = both peers. The standard behavior in this case would include the following elements: 1. LACP synchronizes priorities locally set for each link (so that each pee= r considers the candidate links in exactly the same order) 2. M < N links w= ith highest priorities are bi-directionally agreed upon as both collecting = and distributing using LAG. 3. The remaining (M-N) healthy links are still monitored by LACP but do no= t carry client traffic, and LACP advertises them as neither" collecting "no= r "distributing". How is this going to change with the introduction of BLM? In particular: 1. Would micro-BFD sessions run on inactive LAG members? 2. Suppose that one of the high priority links goes down, and the micro-BFD= session indicates that two inactive links are healthy - would the link wit= h the highest priority be selected for activation?=20 3. Once the new link has been selected, what state would LACP advertise for= it? (My understanding is that activation of a link starts with declaring i= t as "collecting but not distributing", and it passes to "collecting and di= stributing" only after seeing that the partner state is "collecting", but = I am not sure that the 802.1AX standard dictates this.) 4. Would the LAG tr= y to send user traffic on a link with a healthy micro-BFD session even if t= he peer is still advertising its state (via LACP) as "not collecting"? And= what would happen to the traffic received from such a link? In a different scenario, suppose that one of the links has been misconfigur= ed with LAG ID that differs from that of the links on the other side.=20 1. What is supposed to happen to its micro-BFD session (would it be started= , could it reach UP state etc.) 2. Would the LAG try to send traffic via su= ch a link if its micro-BFD session is UP? The answer is not clear to me because the draft simply states that "BFD tak= es precedence over LACP in deciding the fate of individual member links wh= en both are run in parallel". This can be interpreted in many ways. =20 Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Bhatia, Manav (Manav) > Sent: Monday, December 19, 2011 12:30 PM > To: rtg-bfd@ietf.org > Subject: BFDoLAGs Updated >=20 > Hi WG members, >=20 > We have posted a revised version of the BFD over LAGs draft. >=20 > Its available here: > http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt >=20 > Diff beween the -00 and the -01 version: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-01.txt >=20 > Would be great if the WG members can review this version and provide=20 > feedback. >=20 > We have also included a small discussion on Unicast vs Multicast=20 > encapsulation. > https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >=20 > Cheers, Manav This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Thu Dec 22 22:40:46 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 EC4FE21F8AAC for ; Thu, 22 Dec 2011 22:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=2.256, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evyoUYgHXSdD for ; Thu, 22 Dec 2011 22:40:46 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 9CDB221F89B8 for ; Thu, 22 Dec 2011 22:40:45 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1324622317!49413374!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 852 invoked from network); 23 Dec 2011 06:38:37 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-14.tower-27.messagelabs.com with SMTP; 23 Dec 2011 06:38:37 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-ec-4ef423719981 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id D6.86.08306.17324FE4; Fri, 23 Dec 2011 08:45:05 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.212]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Fri, 23 Dec 2011 08:40:42 +0200 From: Alexander Vainshtein To: Marc Binderberger , Nitin Bahadur Date: Fri, 23 Dec 2011 08:39:19 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: AczA9K/PXvOeSQ5gRiKlbewC3mNj4QASOlmj Message-ID: References: , <6D4CAC2E-DBAE-43C1-A101-28EF5652CA18@sniff.de> In-Reply-To: <6D4CAC2E-DBAE-43C1-A101-28EF5652CA18@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKJsWRmVeSWpSXmKPExsUy+dWnL7qFyl/8DFrfiFvMvvKf2aKht53N 4vOfbYwOzB5Llvxk8rjedJXdo3V1N0sAc1QDo01iXl5+SWJJqkJKanGyrVJAUWZZYnKlkkJm iq2SoZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1 VLJTUzY0tuYKycgsVkjVzU3MzFHITS0uTkxPVQCKJGxhzti2sZux4LtexeV5Z1kbGC+rdDFy cEgImEiseF/YxcgJZIpJXLi3ng3EFhLYySjRPlGoi5ELyJ7CKHF4aRs7SIJNwFZi0+q7YEUi Ap4S3+a2MYHYzAKaEk0nPoPVsAioSmzq/gVmCwsoSayaAGGLCChLbL97nxHCNpK41beMFcTm FQiUeHRnCRPE4niJhVNWsIDYnAI2EnPv3AWLMwId9/3UGqhd4hK3nsxngjhaQGLJnvPMELao xMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WtmiL2CEidnPmGB6JWUOLjiBssERvFZSFbM QtI+C0n7LCTtCxhZVjFKZuYUlCTlphsY6eaXluilJmeWpOak6iXn525ihCSYFzsYb5/RPMQo wMGoxMP7ovOznxBrYllxZe4hRkkOJiVR3q2KX/yE+JLyUyozEosz4otKc1KLDzFKcDArifC+ WABUzpuSWFmVWpQPk7IAhvREZinu5Hxg0swriTc2MEDhKInzdie/8RUSSAemu+zU1ILUIphW GQ4OJQneBpCNgkWp6akVaZk5JQhpJg5OkM08QJurQWp4iwsSc4sz0yHypxgVpcR5e0ESAiCJ jNI8uF5Q7qj/////K0ZxoD+FIdp5gHkHrvsV0GAmoMHbnD+ADAbmCbiUVAOj7mHzC54qj0zm PWYxu6xdWff7HafA3tCl02WuXG2Sbj/AfnGD9bnL3pu2y3FyuBzX94pea6Y4Q+KsuMX0E/aW zw3id8T6hjjZ71pxr1Sk4+CB8682Z8la2ho/XieQpN3Yx33OxLIqdfrD8w0MTM19tQWO7ye/ 7Lfy/ZodJ5fwvuhO6IO2iXuVWIozEg21mIuKEwEy4LFD+AMAAA== Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 06:40:47 -0000 Marc, Nitin and all, Quoting from Marc's email: "I don't think we can get to a conclusion about Unicast/Multicast until we h= ave discussed the other topics and then see what is needed." I fully agree with this statement. Regards, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Marc= Binderberger [marc@sniff.de] Sent: Thursday, December 22, 2011 11:57 PM To: Nitin Bahadur Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG interfaces Hello Nitin, I do not disagree but the goal you define may be too restricted. > The goal should be fast failure detection We should all be able to agree on this. This is the minimum achievement. But already this goal may have two options: with and without LACP. While I w= ould recommend LACP to customers it does not mean it's always possible. Without LACP you likely want to prevent a LAG link "going up" after you just= received a BFD Down state. But how? Even with LACP you could - maybe not a very likely scenario - have LACP conn= ectivity but BFD is interrupted. Again stopping an immediate link "going up"= again may be a good thing. For now I prefer an L3 encaps that is not preventing BFD to control the "goi= ng up". We may drop it when we learn the solution covering, lets say, 90% of= the setups (LACP supported by BFD down?) is small & elegant while the 100%= solution is a complex beast. But we don't know this yet. And of course we don't know if - for a standardization - it is possible to d= efine a packet Rx/Tx API at layer-3. Another reason why I think after a good= discussion about pros and cons of Unicast, Multicast, new UDP port we shoul= d stop that discussion and wait for the outcome of other discussions, e.g. i= nteraction between BFD and 802.1X state machine. (still waiting for Dave Katz to shed some light on the "private API" comment= he made :-) For the "switch in the middle", maybe this wasn't clear but draft-mmm is not= supporting this for the per-member BFD. Nor do I think any other draft I'm= aware of. It's back-to-back. More precise: the per-member sessions and the= overall "BLM" is between directly connected neighbours, as mentioned in RFC= 5882, section 7.3. This is why we allow a combination of it with "BBP" (sing= le session over LAG), as the single session can go through an Ethernet switc= h; this is scenario 7.4 in RFC5882. I assume you mention the switch to explain why the per-interface IP address= is a good thing, as it allows a check if the BFD packet arrived at the righ= t interface? Now for LAG we have N ports and all the BFD packets arriving wi= ll have the same destination IP address if you use the interface IP; I thin= k this IP check must be dropped for micro sessions. Instead the "interface information" must be used. Or some out-of-band mechan= ism informs you about the remove discriminator, similar to RFC5884 (I'm not= promoting this, I don't like it too much due to the complexity but for the= sake of a more complete discussion I mention it) "Interface information" is another interesting point for the Rx/Tx API in th= e standard. Can we demand this information for a layer-3 API? (not asking if we code-wise can do it. We probably all _do_ already). Too long, my email. In short: I don't think we can get to a conclusion about= Unicast/Multicast until we have discussed the other topics and then see wha= t is needed. Regards, Marc On 2011-12-22, at 20:58 , Nitin Bahadur wrote: > > And just to clarify a little bit more.... > > I don't want BFD to replace LACP. I want it to supplement LACP. Just like= today if we run BFD for OSPF adjacencies, we don't get rid of OSPF hellos..= . > But if the BFD session goes down, we tell OSPF about it and OSPF reacts to= that. Similarly (pardon my lack of knowledge about LACP), LACP can react to > BFD member sessions down. The link can be brought up by LACP at a slower i= nterval. The goal should be fast failure detection and not necessarily fast > Link-up following a failure correction. > > Thanks > Nitin > > On 12/22/11 11:34 AM, "Nitin Bahadur" wrote: > > Hi Manav, > >> Using the IP address of the interface leads into a cyclic loop as you can= t bring up the member links since L3 is not up, and >> you cant bring up L3 since the member links are still down. > > I think we are talking of 2 different things here. In vanilla BFD mode tod= ay, the IP link comes up first and then BFD starts on it. BFD in no way > brings down a Sonet link for instance. So why do you want BFD to bring dow= n an Ethernet link? If you want that to happen, you have to use L2 encap > or use ethernet oam. > > If all member links are down, then the AE will be down and L3 will be down= as well. Once a single AE member comes up, the AE bundle should > come up. Once the AE is UP, your ARP will work as well and L3 will come UP= . And then your BFD on that AE member will come as well. > Now that BFD is UP, you can feed that into routing protocols or other prot= ocols that can feed off that. When the 2nd AE member comes up, the 2nd BFD > session will also come up. And you can feed that again into whatever proto= col you want. > > Note that "you can bring the member link UP even when L3 is not up". The m= ember link just comes up itself....maybe I am missing something very basic h= ere. > >> On a point-to-point link isn't the discriminator value good enough to che= ck if the packet is indeed for the recipient? > > On a p2p link yes....but you are assuming that the P2P link doesn'= t have any L2 switches in the middle. If there are L2 switches in the middle= , you > could have mis-routed packets coming in and in that case the disc= riminator value is not sufficient. > > Thanks > Nitin > -- Marc Binderberger This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From manav.bhatia@alcatel-lucent.com Tue Dec 27 07:43:42 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 65D0F21F850D for ; Tue, 27 Dec 2011 07:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNYkDSLVJ68x for ; Tue, 27 Dec 2011 07:43:42 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D9B7721F850B for ; Tue, 27 Dec 2011 07:43:41 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pBRFhaNn012684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Dec 2011 09:43:39 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBRFhZju015968 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Dec 2011 21:13:35 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 27 Dec 2011 21:13:35 +0530 From: "Bhatia, Manav (Manav)" To: Nitin Bahadur , "rtg-bfd@ietf.org" Date: Tue, 27 Dec 2011 21:13:33 +0530 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nAAIeguvwABXIygAZefe2gAANZHOgDyScVw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 15:43:42 -0000 Yes, this sounds reasonable. What we're looking at right now is this: 1. We use LACP to bring up the links.=20 2. We establish micro BFD sessions per link (using ingress port + source MA= C as a unique identifier) 3. If BFD session goes down, we inform the 802.1ax so that it can bring dow= n the state so that the link is NOT used for forwarding. 4. Wait for LACP to bring up the member port of the LAG. Once its UP, BFD s= essions again establish and the process repeats. =20 So, we use BFD only to bring down the link. =20 Once the link is up, we use IP encapsulated BFD (no L2 encap required) with= either unicast or multicast addressing scheme.=20 This solution however requires LACP to work in tandem with the micro BFD se= ssions for the LAG. This will work for all scenarios except the one where a= provider does NOT want to run LACP on the LAG (and I am not sure why someb= ody would NOT want LACP btw). Cheers, Manav > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Friday, December 23, 2011 1:29 AM > To: Nitin Bahadur; Bhatia, Manav (Manav); Jeff Tantsura;=20 > rtg-bfd@ietf.org > Subject: Re: BFD on LAG interfaces >=20 >=20 > And just to clarify a little bit more.... >=20 > I don't want BFD to replace LACP. I want it to supplement=20 > LACP. Just like today if we run BFD for OSPF adjacencies, we=20 > don't get rid of OSPF hellos... > But if the BFD session goes down, we tell OSPF about it and=20 > OSPF reacts to that. Similarly (pardon my lack of knowledge=20 > about LACP), LACP can react to BFD member sessions down. The=20 > link can be brought up by LACP at a slower interval. The goal=20 > should be fast failure detection and not necessarily fast=20 > Link-up following a failure correction. >=20 > Thanks > Nitin >=20 From Alexander.Vainshtein@ecitele.com Tue Dec 27 11:03:41 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 15F4021F856F for ; Tue, 27 Dec 2011 11:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=1.504, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbZd4-zW8quL for ; Tue, 27 Dec 2011 11:03:40 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id A501021F8545 for ; Tue, 27 Dec 2011 11:03:39 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1325012561!58776805!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 27784 invoked from network); 27 Dec 2011 19:02:44 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-2.tower-27.messagelabs.com with SMTP; 27 Dec 2011 19:02:44 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-1d-4efa178a5917 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id AF.9A.08306.A871AFE4; Tue, 27 Dec 2011 21:07:54 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 27 Dec 2011 21:03:36 +0200 From: Alexander Vainshtein To: "Bhatia, Manav (Manav)" , Nitin Bahadur , "rtg-bfd@ietf.org" Date: Tue, 27 Dec 2011 20:59:40 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: Acy5xAc2rqbrLGipReylGpRIoRTZpQACHsCAAAos+nAAIeguvwABXIygAZefe2gAANZHOgDyScVwAAcbIqM= Message-ID: References: , <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTe0gTcRznt9vjXDu9prafVrBuFT2cbWkw0ZlEgRGZPSCorM7br9vh7jZ2 p7SiWpYYSmgoRFKYYA806EEvywgtiCzKoDAr7f1aFtHLtMjudmlG99fnd5/X747vF8fMPfpk nBMkFBRoH6U3amsin77YKy2DeY7TLcC1v7dX5wrvLte7Pv88C3Kw3LJXl3S5jY0Dmtyu0nuG fGxVGGTRguCXaAlZPUhk3FR+kCuhmRBl5TxuyklZAz6aQTwSJDdFBwJI8FDZRut/T5Ys4wQr Ehi/hxNYN7Vw+RK7yzUnw+6ksqfanGmZxhVeTrQiO09zPiuPRJFmkVV+s/405n3a2m4IdMdv bIu81IVBZ1wFiMEhmQ5flh8AKh4HO3uP6yuAETeTLQA+Htj+51AL4M3uVp2i0pNueKq5J0ok kBUA3q1v0SuElpwCmzv2GhQcT1KwqXowihNIGzzX8xiouBDW7myIBhHkUnjr9R2D2nAEwG9n rkSDYsi1sLrpclQE5Dv1dxzTKBgjLfDBi3qNelcSNrbexlScCN8+//VHnwgflR8Hqj4FHrz4 Sa/imfBwwztMLR4Lr+97oVW9SbDt6H1tNRhXN6qibpS9bpS9bpT9INA2gSTOF5AKedYx2+4v llIRw0nIh1IZP38KqIPy5jx4eHN6OyBxQJkI58eBPLOOLhFDfDtIwjVUIhGJG8wzxxb6PSEv LXrXBYt9SGwHEMeoBCLjiSwnPHRoEwr6hymX/Kv3YMljGL88koK0Ls3h+OdAWYhKpm+xmWTl eStCKICCw9YJOE5B4r1ZbhwbRCzauIHzSX9pDR6jNJvk5meKhhADNC9yrMp3gEnJFuKyQpAK 4S0WRrzKVmwbGhqKAIv8nfFqhUnemRF3RA7WyMFrbd+VYHkXRqjkMCjg68OTV3v6hGVz8y4w 51s6ZxUWGUJ3vRdjx3yI/bqruCSHNA3dyN+T9JQ1bPnZbwNdgQdOg6No2tRr2wZNxq2Levl5 7zJdJ9dPdnaxVSuLyqoWzWZ313Rc+FGVHjd/Ykb3vWnmQ6UDOz5eTdGCLFtqlnfNiVkfHo6v 37ygoHJGikhpRS/tnIEFRfo3v3vpAfADAAA= X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:03:41 -0000 Manav, The scheme you've presented looks OK to me. Regarding your question - why somebody would NOT want LACP - I can only add= that micro-BFD sessions, in my opinion, are used to replace lacking failure= indications from the physical layer. In these scenarios working without LAC= P would be quite problematic in any case... (Not sure if this is the right answer, but it is the best one I can give:-) Regards, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Bhati= a, Manav (Manav) [manav.bhatia@alcatel-lucent.com] Sent: Tuesday, December 27, 2011 5:43 PM To: Nitin Bahadur; rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Yes, this sounds reasonable. What we're looking at right now is this: 1. We use LACP to bring up the links. 2. We establish micro BFD sessions per link (using ingress port + source MAC= as a unique identifier) 3. If BFD session goes down, we inform the 802.1ax so that it can bring down= the state so that the link is NOT used for forwarding. 4. Wait for LACP to bring up the member port of the LAG. Once its UP, BFD se= ssions again establish and the process repeats. So, we use BFD only to bring down the link. Once the link is up, we use IP encapsulated BFD (no L2 encap required) with= either unicast or multicast addressing scheme. This solution however requires LACP to work in tandem with the micro BFD ses= sions for the LAG. This will work for all scenarios except the one where a p= rovider does NOT want to run LACP on the LAG (and I am not sure why somebody= would NOT want LACP btw). Cheers, Manav > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Friday, December 23, 2011 1:29 AM > To: Nitin Bahadur; Bhatia, Manav (Manav); Jeff Tantsura; > rtg-bfd@ietf.org > Subject: Re: BFD on LAG interfaces > > > And just to clarify a little bit more.... > > I don't want BFD to replace LACP. I want it to supplement > LACP. Just like today if we run BFD for OSPF adjacencies, we > don't get rid of OSPF hellos... > But if the BFD session goes down, we tell OSPF about it and > OSPF reacts to that. Similarly (pardon my lack of knowledge > about LACP), LACP can react to BFD member sessions down. The > link can be brought up by LACP at a slower interval. The goal > should be fast failure detection and not necessarily fast > Link-up following a failure correction. > > Thanks > Nitin > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From marc@sniff.de Thu Dec 29 01:00: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 BF76721F85C7 for ; Thu, 29 Dec 2011 01:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYna-n6X9YHV for ; Thu, 29 Dec 2011 01:00:32 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 768FB21F8591 for ; Thu, 29 Dec 2011 01:00:31 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 7BDD12AA0F; Thu, 29 Dec 2011 09:00:26 +0000 (GMT) Subject: Re: BFDoLAGs Updated Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Thu, 29 Dec 2011 10:00:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <00D10265-E9EE-405F-AA02-C63ACCD416E5@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Gregory Mirsky 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: Thu, 29 Dec 2011 09:00:32 -0000 Hello Gregory, > * Section 2.1, second para. I strongly disagree that IETF needs to = standardize what is referred as "BFD over Big Pipe". I think it is more = useful to take this discussion into Informational document where = different implementations can be described and recommendations to = interoperate provided. And I strongly disagree with your disagreement :-) Seriously: the BFD over Big Pipe ("BBP" for short) is used in the draft = in combination with "BLM" (the BFD over LAG member), so it must be = defined. This is where I also disagree with "informational document". Do we need to define it in the same draft as BLM? Can be debated. It = seemed practical to do but if the opinion is we need a separate draft = then we can do so as well. > * Section 3.3 If standardization of the evaluation function put = outside of the scope of the document then role of the Concluded BFD = state is out of scope as well (second bullet in Section 4). Doesn't make sense. The document defines the BLM session, the concluded = state is part of that session, so it must be defined in this draft, = including what it is for. Maybe this is a matter of wording? "outside scope" vs. "implementation = detail"? In any case, we can define one evaluation function in the = draft that MUST be implemented (but allow for alternative functions as = well) if your concern is interoperability - is it? (using the concluded state to influence the BBP session state is = addressing any difference between the peer's evaluation function, btw) Thanks for the feedback! REgards, Marc > * Section 7 considering discussion in Appendix A.1 I think that = suggestion that request for link-local multicast IP addresses will be = made is premature. > * A.1 One of advantages of Unicast IP address, I suggest use of = 127/8 range, used as destination IP address for IP/UDP encapsulation of = control packets for micro-BFD is that each micro-BFD session might be = assigned unique destination IP address. And I don't see any of listed = disadvantages playing any role if destination IP address selected from = 127/8 range. > * A.2 Use of Ethernet multicast address can be suggested if = operator is certain that LAG member is p2p in L2 sense. Otherwise, = unicast Ethernet address should be used.=20 >=20 > Thank you for your kind consideration. >=20 > Regards, > Greg=20 >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Alexander Vainshtein > Sent: Monday, December 19, 2011 4:21 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: BFDoLAGs Updated >=20 > Manav, and all, > I've looked up the -01 version of the draft. It seems to address some = of my earlier concerns (mainly dealing with various possible = encapsulations) but, IMHO, still leaves the critical architectural = issues unresolved. >=20 > Please consider the following scenario: >=20 > A LAG comprises N potential member links but limits the number of = concurrently active links to M < N. > Priorities of the links are exchanged via LACP (which also guarantees = that all the potential links have been, indeed, associated with the same = LAG by both peers. > The standard behavior in this case would include the following = elements: >=20 > 1. LACP synchronizes priorities locally set for each link (so that = each peer considers the candidate links in exactly the same order) 2. M = < N links with highest priorities are bi-directionally agreed upon as = both collecting and distributing using LAG. > 3. The remaining (M-N) healthy links are still monitored by LACP but = do not carry client traffic, and LACP advertises them as neither" = collecting "nor "distributing". >=20 > How is this going to change with the introduction of BLM? >=20 > In particular: >=20 > 1. Would micro-BFD sessions run on inactive LAG members? > 2. Suppose that one of the high priority links goes down, and the = micro-BFD session indicates that two inactive links are healthy - would = the link with the highest priority be selected for activation?=20 > 3. Once the new link has been selected, what state would LACP = advertise for it? (My understanding is that activation of a link starts = with declaring it as "collecting but not distributing", and it passes to = "collecting and distributing" only after seeing that the partner state = is "collecting", but I am not sure that the 802.1AX standard dictates = this.) 4. Would the LAG try to send user traffic on a link with a = healthy micro-BFD session even if the peer is still advertising its = state (via LACP) as "not collecting"? And what would happen to the = traffic received from such a link? >=20 > In a different scenario, suppose that one of the links has been = misconfigured with LAG ID that differs from that of the links on the = other side.=20 >=20 > 1. What is supposed to happen to its micro-BFD session (would it be = started, could it reach UP state etc.) 2. Would the LAG try to send = traffic via such a link if its micro-BFD session is UP? >=20 >=20 > The answer is not clear to me because the draft simply states that = "BFD takes precedence over LACP in deciding the fate of individual = member links when both are run in parallel". This can be interpreted in = many ways. >=20 >=20 >=20 >=20 >=20 >=20 > Regards, > Sasha >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >> Behalf Of Bhatia, Manav (Manav) >> Sent: Monday, December 19, 2011 12:30 PM >> To: rtg-bfd@ietf.org >> Subject: BFDoLAGs Updated >>=20 >> Hi WG members, >>=20 >> We have posted a revised version of the BFD over LAGs draft. >>=20 >> Its available here: >> http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt >>=20 >> Diff beween the -00 and the -01 version: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-01.txt >>=20 >> Would be great if the WG members can review this version and provide=20= >> feedback. >>=20 >> We have also included a small discussion on Unicast vs Multicast=20 >> encapsulation. >> https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >>=20 >> Cheers, Manav >=20 >=20 > This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >=20 -- Marc Binderberger From toms.sanders@gmail.com Thu Dec 29 07:38:21 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 3C06921F85B1 for ; Thu, 29 Dec 2011 07:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg04qAIznW0u for ; Thu, 29 Dec 2011 07:38:20 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6983221F8545 for ; Thu, 29 Dec 2011 07:38:18 -0800 (PST) Received: by wibhj6 with SMTP id hj6so7933077wib.31 for ; Thu, 29 Dec 2011 07:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=371D506DZrnoeHxV0E/f5LcYGmVrDYC0XivxfDZjSpM=; b=M6oDWlpM/H0wXdIESfLZmd/imzeMmzhFnEVAdBPK7mgB5ZuGKv3HQwyFweI5AuuWIc aSt8Klf0SFUum6+mGV8lHSXp2b56kmsFxz7oQroa3hn7rXeCTM/ddmsDfu/BxbE8jSDO 0sYaREKrQZh17p1SK98pXwJr4QnLZ2Btqs/x0= MIME-Version: 1.0 Received: by 10.180.8.229 with SMTP id u5mr79401253wia.9.1325173097634; Thu, 29 Dec 2011 07:38:17 -0800 (PST) Received: by 10.223.120.77 with HTTP; Thu, 29 Dec 2011 07:38:16 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Thu, 29 Dec 2011 21:08:16 +0530 Message-ID: Subject: Re: BFD on LAG interfaces From: Tom Sanders To: Alexander Vainshtein Content-Type: text/plain; charset=UTF-8 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: Thu, 29 Dec 2011 15:38:21 -0000 Sasha, I agree. Instead of us speculating, can the operators who are on this list speak on whether they are looking at BFD managing their LAGs without LACP? If Yes, then why do they want this? It would be a shame to over-engineer a solution when a simple one is available. Toms On 28 December 2011 00:29, Alexander Vainshtein wrote: > Manav, > The scheme you've presented looks OK to me. > > Regarding your question - why somebody would NOT want LACP - I can only a= dd that micro-BFD sessions, in my opinion, are used to replace lacking fail= ure indications from the physical layer. In these scenarios working without= LACP would be quite problematic in any case... > > (Not sure if this is the right answer, but it is the best one I can give:= -) > > Regards, > =C2=A0 =C2=A0 Sasha > > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Bh= atia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Tuesday, December 27, 2011 5:43 PM > To: Nitin Bahadur; rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces > > Yes, this sounds reasonable. > > What we're looking at right now is this: > > 1. We use LACP to bring up the links. > 2. We establish micro BFD sessions per link (using ingress port + source = MAC as a unique identifier) > 3. If BFD session goes down, we inform the 802.1ax so that it can bring d= own the state so that the link is NOT used for forwarding. > 4. Wait for LACP to bring up the member port of the LAG. Once its UP, BFD= sessions again establish and the process repeats. > > So, we use BFD only to bring down the link. > > Once the link is up, we use IP encapsulated BFD (no L2 encap required) wi= th either unicast or multicast addressing scheme. > > This solution however requires LACP to work in tandem with the micro BFD = sessions for the LAG. This will work for all scenarios except the one where= a provider does NOT want to run LACP on the LAG (and I am not sure why som= ebody would NOT want LACP btw). > > Cheers, Manav > >> -----Original Message----- >> From: Nitin Bahadur [mailto:nitinb@juniper.net] >> Sent: Friday, December 23, 2011 1:29 AM >> To: Nitin Bahadur; Bhatia, Manav (Manav); Jeff Tantsura; >> rtg-bfd@ietf.org >> Subject: Re: BFD on LAG interfaces >> >> >> And just to clarify a little bit more.... >> >> I don't want BFD to replace LACP. I want it to supplement >> LACP. Just like today if we run BFD for OSPF adjacencies, we >> don't get rid of OSPF hellos... >> But if the BFD session goes down, we tell OSPF about it and >> OSPF reacts to that. Similarly (pardon my lack of knowledge >> about LACP), LACP can react to BFD member sessions down. The >> link can be brought up by LACP at a slower interval. The goal >> should be fast failure detection and not necessarily fast >> Link-up following a failure correction. >> >> Thanks >> Nitin >> > > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > --=20 Toms. From marc@sniff.de Thu Dec 29 09:23:46 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 02A2E21F8AF0 for ; Thu, 29 Dec 2011 09:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyfSWNo9TylE for ; Thu, 29 Dec 2011 09:23:45 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4A121F8AE1 for ; Thu, 29 Dec 2011 09:23:44 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 482952AA0F; Thu, 29 Dec 2011 17:23:42 +0000 (GMT) Subject: Re: BFD on LAG interfaces Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Thu, 29 Dec 2011 18:23:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <53895367-8D87-4492-9D19-64FCC5488476@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> To: Alexander Vainshtein , Tom Sanders 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: Thu, 29 Dec 2011 17:23:46 -0000 Hello Tom, Alexander et al., in general I agree with your statements. BFD is _not_ LACP. BFD should = be planned as a booster for the detection. And keep it simple. On the = other hand we need answers for the various cases. The problem is to bring up the link with protocol P1 but bring it down = with protocol P2. The underlying assumption is that P1 is interrupted as = well when P2 goes down. True for a clean link cut, questionable if = something goes wrong with the layer-3 alone. Then P1 (LACP or L1) may be = up and thus the LAG port is active while P2 (BFD) stays down. Maybe we can live with it (?). As far as I know about existing implementations they seem to avoid the = above situation by either: (i) use BFD to control - alone or in combination with LACP - the port = going active and going down (ii) use BFD to update routing protocols alone but do not affect the = LAG. Maybe someone has implemented the "P1 brings up, P2 brings down" and can = talk about the experience? Regards, Marc On 2011-12-29, at 16:38 , Tom Sanders wrote: > Sasha, >=20 > I agree. Instead of us speculating, can the operators who are on this > list speak on whether they are looking at BFD managing their LAGs > without LACP? If Yes, then why do they want this? It would be a shame > to over-engineer a solution when a simple one is available. >=20 > Toms >=20 > On 28 December 2011 00:29, Alexander Vainshtein > wrote: >> Manav, >> The scheme you've presented looks OK to me. >>=20 >> Regarding your question - why somebody would NOT want LACP - I can = only add that micro-BFD sessions, in my opinion, are used to replace = lacking failure indications from the physical layer. In these scenarios = working without LACP would be quite problematic in any case... >>=20 >> (Not sure if this is the right answer, but it is the best one I can = give:-) >>=20 >> Regards, >> Sasha >>=20 >> ________________________________________ >> From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] >> Sent: Tuesday, December 27, 2011 5:43 PM >> To: Nitin Bahadur; rtg-bfd@ietf.org >> Subject: RE: BFD on LAG interfaces >>=20 >> Yes, this sounds reasonable. >>=20 >> What we're looking at right now is this: >>=20 >> 1. We use LACP to bring up the links. >> 2. We establish micro BFD sessions per link (using ingress port + = source MAC as a unique identifier) >> 3. If BFD session goes down, we inform the 802.1ax so that it can = bring down the state so that the link is NOT used for forwarding. >> 4. Wait for LACP to bring up the member port of the LAG. Once its UP, = BFD sessions again establish and the process repeats. >>=20 >> So, we use BFD only to bring down the link. >>=20 >> Once the link is up, we use IP encapsulated BFD (no L2 encap = required) with either unicast or multicast addressing scheme. >>=20 >> This solution however requires LACP to work in tandem with the micro = BFD sessions for the LAG. This will work for all scenarios except the = one where a provider does NOT want to run LACP on the LAG (and I am not = sure why somebody would NOT want LACP btw). >>=20 >> Cheers, Manav >>=20 >>> -----Original Message----- >>> From: Nitin Bahadur [mailto:nitinb@juniper.net] >>> Sent: Friday, December 23, 2011 1:29 AM >>> To: Nitin Bahadur; Bhatia, Manav (Manav); Jeff Tantsura; >>> rtg-bfd@ietf.org >>> Subject: Re: BFD on LAG interfaces >>>=20 >>>=20 >>> And just to clarify a little bit more.... >>>=20 >>> I don't want BFD to replace LACP. I want it to supplement >>> LACP. Just like today if we run BFD for OSPF adjacencies, we >>> don't get rid of OSPF hellos... >>> But if the BFD session goes down, we tell OSPF about it and >>> OSPF reacts to that. Similarly (pardon my lack of knowledge >>> about LACP), LACP can react to BFD member sessions down. The >>> link can be brought up by LACP at a slower interval. The goal >>> should be fast failure detection and not necessarily fast >>> Link-up following a failure correction. >>>=20 >>> Thanks >>> Nitin >>>=20 >>=20 >> This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >>=20 >=20 >=20 >=20 > --=20 > Toms. >=20 -- Marc Binderberger From gregory.mirsky@ericsson.com Thu Dec 29 10:34:27 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 EF4CA21F8B55 for ; Thu, 29 Dec 2011 10:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXiPrK1HZSdl for ; Thu, 29 Dec 2011 10:34:27 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1785521F8B45 for ; Thu, 29 Dec 2011 10:34:27 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBTIYL6k000316; Thu, 29 Dec 2011 12:34:23 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Dec 2011 13:34:16 -0500 From: Gregory Mirsky To: Marc Binderberger Date: Thu, 29 Dec 2011 13:34:14 -0500 Subject: RE: BFDoLAGs Updated Thread-Topic: BFDoLAGs Updated Thread-Index: AczGCFGFzMK0YabkSISTPrq0v1w8+wATguFA Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> <00D10265-E9EE-405F-AA02-C63ACCD416E5@sniff.de> In-Reply-To: <00D10265-E9EE-405F-AA02-C63ACCD416E5@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:34:28 -0000 Dear Marc, et al., Thank you for taking time to respond in this busy holiday season. I believe that we will be better off by defining requirements for BFD over = LAG, a.k.a. BFD over Big Pipe, rather than specific variant of implementati= on known to authors. Is Concluded BFD State intended to replace LACP as it is defined in IEEE 80= 2.1ax-2008? I think that it is beneficial to define BFD over Ethernet encapsulation per= haps in two variants - with IP/UDP header and without one. And I agree with= Sasha and Tom (another thread of the discussion) that to view BFD over LAG= member (BLM) as equivalent of indication of Layer 1 connectivity (though i= t is not only that). Regards, Greg -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Thursday, December 29, 2011 1:00 AM To: Gregory Mirsky Cc: Bhatia, Manav (Manav); rtg-bfd@ietf.org Subject: Re: BFDoLAGs Updated Hello Gregory, > * Section 2.1, second para. I strongly disagree that IETF needs to standa= rdize what is referred as "BFD over Big Pipe". I think it is more useful to= take this discussion into Informational document where different implement= ations can be described and recommendations to interoperate provided. And I strongly disagree with your disagreement :-) Seriously: the BFD over Big Pipe ("BBP" for short) is used in the draft in = combination with "BLM" (the BFD over LAG member), so it must be defined. Th= is is where I also disagree with "informational document". Do we need to define it in the same draft as BLM? Can be debated. It seemed= practical to do but if the opinion is we need a separate draft then we can= do so as well. > * Section 3.3 If standardization of the evaluation function put outside o= f the scope of the document then role of the Concluded BFD state is out of = scope as well (second bullet in Section 4). Doesn't make sense. The document defines the BLM session, the concluded sta= te is part of that session, so it must be defined in this draft, including = what it is for. Maybe this is a matter of wording? "outside scope" vs. "implementation deta= il"? In any case, we can define one evaluation function in the draft that = MUST be implemented (but allow for alternative functions as well) if your c= oncern is interoperability - is it? (using the concluded state to influence the BBP session state is addressing= any difference between the peer's evaluation function, btw) Thanks for the feedback! REgards, Marc > * Section 7 considering discussion in Appendix A.1 I think that suggestio= n that request for link-local multicast IP addresses will be made is premat= ure. > * A.1 One of advantages of Unicast IP address, I suggest use of 127/8 ran= ge, used as destination IP address for IP/UDP encapsulation of control pack= ets for micro-BFD is that each micro-BFD session might be assigned unique d= estination IP address. And I don't see any of listed disadvantages playing = any role if destination IP address selected from 127/8 range. > * A.2 Use of Ethernet multicast address can be suggested if operator is c= ertain that LAG member is p2p in L2 sense. Otherwise, unicast Ethernet addr= ess should be used.=20 >=20 > Thank you for your kind consideration. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Alexander Vainshtein > Sent: Monday, December 19, 2011 4:21 AM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: RE: BFDoLAGs Updated >=20 > Manav, and all, > I've looked up the -01 version of the draft. It seems to address some of = my earlier concerns (mainly dealing with various possible encapsulations) b= ut, IMHO, still leaves the critical architectural issues unresolved. >=20 > Please consider the following scenario: >=20 > A LAG comprises N potential member links but limits the number of concurr= ently active links to M < N. > Priorities of the links are exchanged via LACP (which also guarantees tha= t all the potential links have been, indeed, associated with the same LAG b= y both peers. > The standard behavior in this case would include the following elements: >=20 > 1. LACP synchronizes priorities locally set for each link (so that each p= eer considers the candidate links in exactly the same order) 2. M < N links= with highest priorities are bi-directionally agreed upon as both collectin= g and distributing using LAG. > 3. The remaining (M-N) healthy links are still monitored by LACP but do n= ot carry client traffic, and LACP advertises them as neither" collecting "n= or "distributing". >=20 > How is this going to change with the introduction of BLM? >=20 > In particular: >=20 > 1. Would micro-BFD sessions run on inactive LAG members? > 2. Suppose that one of the high priority links goes down, and the micro-B= FD session indicates that two inactive links are healthy - would the link w= ith the highest priority be selected for activation?=20 > 3. Once the new link has been selected, what state would LACP advertise f= or it? (My understanding is that activation of a link starts with declaring= it as "collecting but not distributing", and it passes to "collecting and = distributing" only after seeing that the partner state is "collecting", bu= t I am not sure that the 802.1AX standard dictates this.) 4. Would the LAG = try to send user traffic on a link with a healthy micro-BFD session even if= the peer is still advertising its state (via LACP) as "not collecting"? A= nd what would happen to the traffic received from such a link? >=20 > In a different scenario, suppose that one of the links has been misconfig= ured with LAG ID that differs from that of the links on the other side.=20 >=20 > 1. What is supposed to happen to its micro-BFD session (would it be start= ed, could it reach UP state etc.) 2. Would the LAG try to send traffic via = such a link if its micro-BFD session is UP? >=20 >=20 > The answer is not clear to me because the draft simply states that "BFD t= akes precedence over LACP in deciding the fate of individual member links = when both are run in parallel". This can be interpreted in many ways. >=20 >=20 >=20 >=20 >=20 >=20 > Regards, > Sasha >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >> Behalf Of Bhatia, Manav (Manav) >> Sent: Monday, December 19, 2011 12:30 PM >> To: rtg-bfd@ietf.org >> Subject: BFDoLAGs Updated >>=20 >> Hi WG members, >>=20 >> We have posted a revised version of the BFD over LAGs draft. >>=20 >> Its available here: >> http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt >>=20 >> Diff beween the -00 and the -01 version: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-01.txt >>=20 >> Would be great if the WG members can review this version and provide=20 >> feedback. >>=20 >> We have also included a small discussion on Unicast vs Multicast=20 >> encapsulation. >> https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >>=20 >> Cheers, Manav >=20 >=20 > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. >=20 -- Marc Binderberger From gregory.mirsky@ericsson.com Thu Dec 29 11:10:58 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 69D7521F8B6E for ; Thu, 29 Dec 2011 11:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxS5MbZo33V9 for ; Thu, 29 Dec 2011 11:10:57 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id AEE9921F8B44 for ; Thu, 29 Dec 2011 11:10:57 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pBTJAkIi027806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Dec 2011 13:10:47 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 29 Dec 2011 14:10:46 -0500 From: Gregory Mirsky To: Tom Sanders , Alexander Vainshtein Date: Thu, 29 Dec 2011 14:10:45 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: AczGP+uv2kzuz1IbSumdgwfmkizbmwAGlayQ Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 29 Dec 2011 19:10:58 -0000 Dear Sasha, tom, et al., I concur with Sasha and Tom that in presence of LACP so-called micro-BFD, a= .k.a. BFD over LAG member link(s), can be viewed as substitute to Layer 1 f= ailure indication. IMHO, use of micro-BFD without LACP or with propritary e= xtensions of LACP (mLACP) might be for further study. But it looks as to re= place LACP we'll need to change character of BFD from simple connectivity m= onitoring to make it TE-aware. Regards, Greg =20 -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Tom Sanders Sent: Thursday, December 29, 2011 7:38 AM To: Alexander Vainshtein Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG interfaces Sasha, I agree. Instead of us speculating, can the operators who are on this list = speak on whether they are looking at BFD managing their LAGs without LACP? = If Yes, then why do they want this? It would be a shame to over-engineer a = solution when a simple one is available. Toms On 28 December 2011 00:29, Alexander Vainshtein wrote: > Manav, > The scheme you've presented looks OK to me. > > Regarding your question - why somebody would NOT want LACP - I can only a= dd that micro-BFD sessions, in my opinion, are used to replace lacking fail= ure indications from the physical layer. In these scenarios working without= LACP would be quite problematic in any case... > > (Not sure if this is the right answer, but it is the best one I can=20 > give:-) > > Regards, > =A0 =A0 Sasha > > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of=20 > Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > Sent: Tuesday, December 27, 2011 5:43 PM > To: Nitin Bahadur; rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces > > Yes, this sounds reasonable. > > What we're looking at right now is this: > > 1. We use LACP to bring up the links. > 2. We establish micro BFD sessions per link (using ingress port +=20 > source MAC as a unique identifier) 3. If BFD session goes down, we inform= the 802.1ax so that it can bring down the state so that the link is NOT us= ed for forwarding. > 4. Wait for LACP to bring up the member port of the LAG. Once its UP, BFD= sessions again establish and the process repeats. > > So, we use BFD only to bring down the link. > > Once the link is up, we use IP encapsulated BFD (no L2 encap required) wi= th either unicast or multicast addressing scheme. > > This solution however requires LACP to work in tandem with the micro BFD = sessions for the LAG. This will work for all scenarios except the one where= a provider does NOT want to run LACP on the LAG (and I am not sure why som= ebody would NOT want LACP btw). > > Cheers, Manav > >> -----Original Message----- >> From: Nitin Bahadur [mailto:nitinb@juniper.net] >> Sent: Friday, December 23, 2011 1:29 AM >> To: Nitin Bahadur; Bhatia, Manav (Manav); Jeff Tantsura;=20 >> rtg-bfd@ietf.org >> Subject: Re: BFD on LAG interfaces >> >> >> And just to clarify a little bit more.... >> >> I don't want BFD to replace LACP. I want it to supplement LACP. Just=20 >> like today if we run BFD for OSPF adjacencies, we don't get rid of=20 >> OSPF hellos... >> But if the BFD session goes down, we tell OSPF about it and OSPF=20 >> reacts to that. Similarly (pardon my lack of knowledge about LACP),=20 >> LACP can react to BFD member sessions down. The link can be brought=20 >> up by LACP at a slower interval. The goal should be fast failure=20 >> detection and not necessarily fast Link-up following a failure=20 >> correction. >> >> Thanks >> Nitin >> > > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > -- Toms. From marc@sniff.de Thu Dec 29 12:22:35 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 EBDAD21F8AF0 for ; Thu, 29 Dec 2011 12:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtC7P8UULN8R for ; Thu, 29 Dec 2011 12:22:35 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8478E21F8AE9 for ; Thu, 29 Dec 2011 12:22:34 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 56BFF2AA0F; Thu, 29 Dec 2011 20:22:32 +0000 (GMT) Subject: Re: BFDoLAGs Updated Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marc Binderberger In-Reply-To: Date: Thu, 29 Dec 2011 21:22:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E50CA47-B7C3-4546-A7E4-D66B3842FE4F@sniff.de> References: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> <00D10265-E9EE-405F-AA02-C63ACCD416E5@sniff.de> To: Gregory Mirsky 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: Thu, 29 Dec 2011 20:22:36 -0000 Hello Gregory, > I believe that we will be better off by defining requirements for BFD = over LAG, a.k.a. BFD over Big Pipe, rather than specific variant of = implementation known to authors. Okay, fair comment. > Is Concluded BFD State intended to replace LACP as it is defined in = IEEE 802.1ax-2008? No. BFD on LAG members (BLM) is a booster for detection. Personally I = would go for a network design that uses LACP to organize the LAG, then = BLM for the detection speed. > I think that it is beneficial to define BFD over Ethernet = encapsulation perhaps in two variants - with IP/UDP header and without = one. Interesting. I have just send "draft-mmm-bfd-on-lags-02-B" to Mach and = Manav, which is a variant of the draft using BFD directly in Ethernet. = And we discuss the IP/UDP variant as well. > And I agree with Sasha and Tom (another thread of the discussion) that = to view BFD over LAG member (BLM) as equivalent of indication of Layer 1 = connectivity (though it is not only that). okay. Thanks a lot for the feedback! REgards, Marc >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de]=20 > Sent: Thursday, December 29, 2011 1:00 AM > To: Gregory Mirsky > Cc: Bhatia, Manav (Manav); rtg-bfd@ietf.org > Subject: Re: BFDoLAGs Updated >=20 > Hello Gregory, >=20 >> * Section 2.1, second para. I strongly disagree that IETF needs to = standardize what is referred as "BFD over Big Pipe". I think it is more = useful to take this discussion into Informational document where = different implementations can be described and recommendations to = interoperate provided. >=20 > And I strongly disagree with your disagreement :-) >=20 > Seriously: the BFD over Big Pipe ("BBP" for short) is used in the = draft in combination with "BLM" (the BFD over LAG member), so it must be = defined. This is where I also disagree with "informational document". >=20 > Do we need to define it in the same draft as BLM? Can be debated. It = seemed practical to do but if the opinion is we need a separate draft = then we can do so as well. >=20 >=20 >> * Section 3.3 If standardization of the evaluation function put = outside of the scope of the document then role of the Concluded BFD = state is out of scope as well (second bullet in Section 4). >=20 > Doesn't make sense. The document defines the BLM session, the = concluded state is part of that session, so it must be defined in this = draft, including what it is for. >=20 > Maybe this is a matter of wording? "outside scope" vs. "implementation = detail"? In any case, we can define one evaluation function in the = draft that MUST be implemented (but allow for alternative functions as = well) if your concern is interoperability - is it? > (using the concluded state to influence the BBP session state is = addressing any difference between the peer's evaluation function, btw) >=20 >=20 > Thanks for the feedback! >=20 > REgards, Marc >=20 >=20 >=20 >=20 >=20 >=20 >> * Section 7 considering discussion in Appendix A.1 I think that = suggestion that request for link-local multicast IP addresses will be = made is premature. >> * A.1 One of advantages of Unicast IP address, I suggest use of = 127/8 range, used as destination IP address for IP/UDP encapsulation of = control packets for micro-BFD is that each micro-BFD session might be = assigned unique destination IP address. And I don't see any of listed = disadvantages playing any role if destination IP address selected from = 127/8 range. >> * A.2 Use of Ethernet multicast address can be suggested if = operator is certain that LAG member is p2p in L2 sense. Otherwise, = unicast Ethernet address should be used.=20 >>=20 >> Thank you for your kind consideration. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >> Behalf Of Alexander Vainshtein >> Sent: Monday, December 19, 2011 4:21 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: RE: BFDoLAGs Updated >>=20 >> Manav, and all, >> I've looked up the -01 version of the draft. It seems to address some = of my earlier concerns (mainly dealing with various possible = encapsulations) but, IMHO, still leaves the critical architectural = issues unresolved. >>=20 >> Please consider the following scenario: >>=20 >> A LAG comprises N potential member links but limits the number of = concurrently active links to M < N. >> Priorities of the links are exchanged via LACP (which also guarantees = that all the potential links have been, indeed, associated with the same = LAG by both peers. >> The standard behavior in this case would include the following = elements: >>=20 >> 1. LACP synchronizes priorities locally set for each link (so that = each peer considers the candidate links in exactly the same order) 2. M = < N links with highest priorities are bi-directionally agreed upon as = both collecting and distributing using LAG. >> 3. The remaining (M-N) healthy links are still monitored by LACP but = do not carry client traffic, and LACP advertises them as neither" = collecting "nor "distributing". >>=20 >> How is this going to change with the introduction of BLM? >>=20 >> In particular: >>=20 >> 1. Would micro-BFD sessions run on inactive LAG members? >> 2. Suppose that one of the high priority links goes down, and the = micro-BFD session indicates that two inactive links are healthy - would = the link with the highest priority be selected for activation?=20 >> 3. Once the new link has been selected, what state would LACP = advertise for it? (My understanding is that activation of a link starts = with declaring it as "collecting but not distributing", and it passes to = "collecting and distributing" only after seeing that the partner state = is "collecting", but I am not sure that the 802.1AX standard dictates = this.) 4. Would the LAG try to send user traffic on a link with a = healthy micro-BFD session even if the peer is still advertising its = state (via LACP) as "not collecting"? And what would happen to the = traffic received from such a link? >>=20 >> In a different scenario, suppose that one of the links has been = misconfigured with LAG ID that differs from that of the links on the = other side.=20 >>=20 >> 1. What is supposed to happen to its micro-BFD session (would it be = started, could it reach UP state etc.) 2. Would the LAG try to send = traffic via such a link if its micro-BFD session is UP? >>=20 >>=20 >> The answer is not clear to me because the draft simply states that = "BFD takes precedence over LACP in deciding the fate of individual = member links when both are run in parallel". This can be interpreted in = many ways. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >> Sasha >>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20= >>> Behalf Of Bhatia, Manav (Manav) >>> Sent: Monday, December 19, 2011 12:30 PM >>> To: rtg-bfd@ietf.org >>> Subject: BFDoLAGs Updated >>>=20 >>> Hi WG members, >>>=20 >>> We have posted a revised version of the BFD over LAGs draft. >>>=20 >>> Its available here: >>> http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt >>>=20 >>> Diff beween the -00 and the -01 version: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-01.txt >>>=20 >>> Would be great if the WG members can review this version and provide=20= >>> feedback. >>>=20 >>> We have also included a small discussion on Unicast vs Multicast=20 >>> encapsulation. >>> https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >>>=20 >>> Cheers, Manav >>=20 >>=20 >> This e-mail message is intended for the recipient only and contains = information which is CONFIDENTIAL and which may be proprietary to ECI = Telecom. If you have received this transmission in error, please inform = us by e-mail, phone or fax, and then delete the original and all copies = thereof. >>=20 >=20 > -- > Marc Binderberger >=20 -- Marc Binderberger From gregory.mirsky@ericsson.com Thu Dec 29 12: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 076DA21F8B62 for ; Thu, 29 Dec 2011 12:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwIGaBL2dMsa for ; Thu, 29 Dec 2011 12:32:48 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id EA34021F8ABD for ; Thu, 29 Dec 2011 12:32:47 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBTKWj1D015545; Thu, 29 Dec 2011 14:32:46 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 29 Dec 2011 15:32:42 -0500 From: Gregory Mirsky To: Marc Binderberger Date: Thu, 29 Dec 2011 15:32:41 -0500 Subject: RE: BFDoLAGs Updated Thread-Topic: BFDoLAGs Updated Thread-Index: AczGZ5wXrQek03wcSq6PeQzMH375FAAATriA Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D026F15CC@INBANSXCHMBSA1.in.alcatel-lucent.com> <00D10265-E9EE-405F-AA02-C63ACCD416E5@sniff.de> <8E50CA47-B7C3-4546-A7E4-D66B3842FE4F@sniff.de> In-Reply-To: <8E50CA47-B7C3-4546-A7E4-D66B3842FE4F@sniff.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 20:32:49 -0000 Dear Marc, Looking forward to -02 version. Happy New Year! Best wishes and good luck to all! Regards, Greg=20 -----Original Message----- From: Marc Binderberger [mailto:marc@sniff.de]=20 Sent: Thursday, December 29, 2011 12:22 PM To: Gregory Mirsky Cc: Bhatia, Manav (Manav); rtg-bfd@ietf.org Subject: Re: BFDoLAGs Updated Hello Gregory, > I believe that we will be better off by defining requirements for BFD ove= r LAG, a.k.a. BFD over Big Pipe, rather than specific variant of implementa= tion known to authors. Okay, fair comment. > Is Concluded BFD State intended to replace LACP as it is defined in IEEE = 802.1ax-2008? No. BFD on LAG members (BLM) is a booster for detection. Personally I would= go for a network design that uses LACP to organize the LAG, then BLM for t= he detection speed. > I think that it is beneficial to define BFD over Ethernet encapsulation p= erhaps in two variants - with IP/UDP header and without one. Interesting. I have just send "draft-mmm-bfd-on-lags-02-B" to Mach and Mana= v, which is a variant of the draft using BFD directly in Ethernet. And we d= iscuss the IP/UDP variant as well. > And I agree with Sasha and Tom (another thread of the discussion) that to= view BFD over LAG member (BLM) as equivalent of indication of Layer 1 conn= ectivity (though it is not only that). okay. Thanks a lot for the feedback! REgards, Marc >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Thursday, December 29, 2011 1:00 AM > To: Gregory Mirsky > Cc: Bhatia, Manav (Manav); rtg-bfd@ietf.org > Subject: Re: BFDoLAGs Updated >=20 > Hello Gregory, >=20 >> * Section 2.1, second para. I strongly disagree that IETF needs to stand= ardize what is referred as "BFD over Big Pipe". I think it is more useful t= o take this discussion into Informational document where different implemen= tations can be described and recommendations to interoperate provided. >=20 > And I strongly disagree with your disagreement :-) >=20 > Seriously: the BFD over Big Pipe ("BBP" for short) is used in the draft i= n combination with "BLM" (the BFD over LAG member), so it must be defined. = This is where I also disagree with "informational document". >=20 > Do we need to define it in the same draft as BLM? Can be debated. It seem= ed practical to do but if the opinion is we need a separate draft then we c= an do so as well. >=20 >=20 >> * Section 3.3 If standardization of the evaluation function put outside = of the scope of the document then role of the Concluded BFD state is out of= scope as well (second bullet in Section 4). >=20 > Doesn't make sense. The document defines the BLM session, the concluded s= tate is part of that session, so it must be defined in this draft, includin= g what it is for. >=20 > Maybe this is a matter of wording? "outside scope" vs. "implementation de= tail"? In any case, we can define one evaluation function in the draft tha= t MUST be implemented (but allow for alternative functions as well) if your= concern is interoperability - is it? > (using the concluded state to influence the BBP session state is=20 > addressing any difference between the peer's evaluation function, btw) >=20 >=20 > Thanks for the feedback! >=20 > REgards, Marc >=20 >=20 >=20 >=20 >=20 >=20 >> * Section 7 considering discussion in Appendix A.1 I think that suggesti= on that request for link-local multicast IP addresses will be made is prema= ture. >> * A.1 One of advantages of Unicast IP address, I suggest use of 127/8 ra= nge, used as destination IP address for IP/UDP encapsulation of control pac= kets for micro-BFD is that each micro-BFD session might be assigned unique = destination IP address. And I don't see any of listed disadvantages playing= any role if destination IP address selected from 127/8 range. >> * A.2 Use of Ethernet multicast address can be suggested if operator is = certain that LAG member is p2p in L2 sense. Otherwise, unicast Ethernet add= ress should be used.=20 >>=20 >> Thank you for your kind consideration. >>=20 >> Regards, >> Greg >>=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >> Behalf Of Alexander Vainshtein >> Sent: Monday, December 19, 2011 4:21 AM >> To: Bhatia, Manav (Manav) >> Cc: rtg-bfd@ietf.org >> Subject: RE: BFDoLAGs Updated >>=20 >> Manav, and all, >> I've looked up the -01 version of the draft. It seems to address some of= my earlier concerns (mainly dealing with various possible encapsulations) = but, IMHO, still leaves the critical architectural issues unresolved. >>=20 >> Please consider the following scenario: >>=20 >> A LAG comprises N potential member links but limits the number of concur= rently active links to M < N. >> Priorities of the links are exchanged via LACP (which also guarantees th= at all the potential links have been, indeed, associated with the same LAG = by both peers. >> The standard behavior in this case would include the following elements: >>=20 >> 1. LACP synchronizes priorities locally set for each link (so that each = peer considers the candidate links in exactly the same order) 2. M < N link= s with highest priorities are bi-directionally agreed upon as both collecti= ng and distributing using LAG. >> 3. The remaining (M-N) healthy links are still monitored by LACP but do = not carry client traffic, and LACP advertises them as neither" collecting "= nor "distributing". >>=20 >> How is this going to change with the introduction of BLM? >>=20 >> In particular: >>=20 >> 1. Would micro-BFD sessions run on inactive LAG members? >> 2. Suppose that one of the high priority links goes down, and the micro-= BFD session indicates that two inactive links are healthy - would the link = with the highest priority be selected for activation?=20 >> 3. Once the new link has been selected, what state would LACP advertise = for it? (My understanding is that activation of a link starts with declarin= g it as "collecting but not distributing", and it passes to "collecting and= distributing" only after seeing that the partner state is "collecting", b= ut I am not sure that the 802.1AX standard dictates this.) 4. Would the LAG= try to send user traffic on a link with a healthy micro-BFD session even i= f the peer is still advertising its state (via LACP) as "not collecting"? = And what would happen to the traffic received from such a link? >>=20 >> In a different scenario, suppose that one of the links has been misconfi= gured with LAG ID that differs from that of the links on the other side.=20 >>=20 >> 1. What is supposed to happen to its micro-BFD session (would it be star= ted, could it reach UP state etc.) 2. Would the LAG try to send traffic via= such a link if its micro-BFD session is UP? >>=20 >>=20 >> The answer is not clear to me because the draft simply states that "BFD = takes precedence over LACP in deciding the fate of individual member links = when both are run in parallel". This can be interpreted in many ways. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >> Sasha >>=20 >>> -----Original Message----- >>> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 >>> Behalf Of Bhatia, Manav (Manav) >>> Sent: Monday, December 19, 2011 12:30 PM >>> To: rtg-bfd@ietf.org >>> Subject: BFDoLAGs Updated >>>=20 >>> Hi WG members, >>>=20 >>> We have posted a revised version of the BFD over LAGs draft. >>>=20 >>> Its available here: >>> http://www.ietf.org/id/draft-mmm-bfd-on-lags-01.txt >>>=20 >>> Diff beween the -00 and the -01 version: >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-01.txt >>>=20 >>> Would be great if the WG members can review this version and provide=20 >>> feedback. >>>=20 >>> We have also included a small discussion on Unicast vs Multicast=20 >>> encapsulation. >>> https://tools.ietf.org/html/draft-mmm-bfd-on-lags-01#appendix-A.1 >>>=20 >>> Cheers, Manav >>=20 >>=20 >> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof. >>=20 >=20 > -- > Marc Binderberger >=20 -- Marc Binderberger From nobo@cisco.com Thu Dec 29 16:33:10 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 414D41F0C4A for ; Thu, 29 Dec 2011 16:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIizNJVuSbyw for ; Thu, 29 Dec 2011 16:33:09 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 443C721F84C9 for ; Thu, 29 Dec 2011 16:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=6819; q=dns/txt; s=iport; t=1325205189; x=1326414789; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=bF1CaTgxRL0oxU3Mz+6EcCZ+SKZCUHbnq73aKpM7dlU=; b=aN0voh22i+mUi1SexhzeqyS8W/gCuD2l1w1dr86sstxrzae35SYkreX9 nS1r2zNDOTOZg3DGurbMxLgOv6dnAcnNx6vKfb0XvFi9q9VNmSPxIzm5i XciU1iLCjoM/DqrVskicRYD7gWeX/cMhHEZk2qqarPc9cduuEXbTd9XNO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAAOQF/U6rRDoJ/2dsb2JhbABDnAuQY4EFgXIBAQEDARIBHQo/BQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggTB4dYl2EBng2LLGMEiDefIA X-IronPort-AV: E=Sophos;i="4.71,430,1320624000"; d="scan'208";a="22991408" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 30 Dec 2011 00:33:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBU0X8K7019086; Fri, 30 Dec 2011 00:33:08 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Dec 2011 16:33:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: BFD on LAG interfaces Date: Thu, 29 Dec 2011 16:33:04 -0800 Message-ID: In-Reply-To: <53895367-8D87-4492-9D19-64FCC5488476@sniff.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: AczGTqL08fyS8yFsRPuFIErgvZ0LnAAOZQ7w References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> <53895367-8D87-4492-9D19-64FCC5488476@sniff.de> From: "Nobo Akiya (nobo)" To: "Marc Binderberger" , "Alexander Vainshtein" , "Tom Sanders" X-OriginalArrivalTime: 30 Dec 2011 00:33:08.0036 (UTC) FILETIME=[9A1E3840:01CCC68A] Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 00:33:10 -0000 Hello Marc, et al, > The problem is to bring up the link with protocol P1 but bring it down > with protocol P2. The underlying assumption is that P1 is interrupted > as well when P2 goes down. True for a clean link cut, questionable if > something goes wrong with the layer-3 alone. Then P1 (LACP or L1) may > be up and thus the LAG port is active while P2 (BFD) stays down. >=20 > Maybe we can live with it (?). "Can we live with it" is indeed the primary question. If consensus is yes, then secondary question becomes what action should LMM take (if any at all)? LMM will know P1 is up but P2 has not come up for "long" time: hours or even days. Should LMM continue to use such link, or should it time out (and stop using the link) eventually? If we want to keep it simple, then the answer here would be "no timeout mechanism" here as well. > Maybe someone has implemented the "P1 brings up, P2 brings down" and can > talk about the experience? I'm curious on this. Side effect here is traffic blackhole. To elaborate the side effect, here are couple of scenarios which can happen. Assumption here is there is one link which P1 is up and P2 has not come up due to layer-3 specific failure. Let's label this link L1. (1) Routing protocols "handshake" happens to take place over non-L1 link and traffic shifts over 802.1ax, but traffic going over L1 will be blackholed. (2) Static route, once 802.1ax state is up, will install route over it, but traffic going over L1 will be blackholed. Certainly would like to hear input from vendors if someone has implemented this model, but would also like to hear from operators if this potential issue is something "we can live this". Regards, Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Marc Binderberger > Sent: Friday, December 30, 2011 2:24 AM > To: Alexander Vainshtein; Tom Sanders > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAG interfaces >=20 > Hello Tom, Alexander et al., >=20 > in general I agree with your statements. BFD is _not_ LACP. BFD should > be planned as a booster for the detection. And keep it simple. On the > other hand we need answers for the various cases. >=20 > The problem is to bring up the link with protocol P1 but bring it down > with protocol P2. The underlying assumption is that P1 is interrupted > as well when P2 goes down. True for a clean link cut, questionable if > something goes wrong with the layer-3 alone. Then P1 (LACP or L1) may > be up and thus the LAG port is active while P2 (BFD) stays down. >=20 > Maybe we can live with it (?). >=20 >=20 > As far as I know about existing implementations they seem to avoid the > above situation by either: >=20 > (i) use BFD to control - alone or in combination with LACP - the port > going active and going down >=20 > (ii) use BFD to update routing protocols alone but do not affect the LAG. >=20 >=20 > Maybe someone has implemented the "P1 brings up, P2 brings down" and can > talk about the experience? >=20 >=20 > Regards, Marc >=20 >=20 >=20 >=20 > On 2011-12-29, at 16:38 , Tom Sanders wrote: >=20 > > Sasha, > > > > I agree. Instead of us speculating, can the operators who are on this > > list speak on whether they are looking at BFD managing their LAGs > > without LACP? If Yes, then why do they want this? It would be a shame > > to over-engineer a solution when a simple one is available. > > > > Toms > > > > On 28 December 2011 00:29, Alexander Vainshtein > > wrote: > >> Manav, > >> The scheme you've presented looks OK to me. > >> > >> Regarding your question - why somebody would NOT want LACP - I can > only add that micro-BFD sessions, in my opinion, are used to replace > lacking failure indications from the physical layer. In these scenarios > working without LACP would be quite problematic in any case... > >> > >> (Not sure if this is the right answer, but it is the best one I can > give:-) > >> > >> Regards, > >> Sasha > >> > >> ________________________________________ > >> From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf > Of Bhatia, Manav (Manav) [manav.bhatia@alcatel-lucent.com] > >> Sent: Tuesday, December 27, 2011 5:43 PM > >> To: Nitin Bahadur; rtg-bfd@ietf.org > >> Subject: RE: BFD on LAG interfaces > >> > >> Yes, this sounds reasonable. > >> > >> What we're looking at right now is this: > >> > >> 1. We use LACP to bring up the links. > >> 2. We establish micro BFD sessions per link (using ingress port + source > MAC as a unique identifier) > >> 3. If BFD session goes down, we inform the 802.1ax so that it can bring > down the state so that the link is NOT used for forwarding. > >> 4. Wait for LACP to bring up the member port of the LAG. Once its UP, > BFD sessions again establish and the process repeats. > >> > >> So, we use BFD only to bring down the link. > >> > >> Once the link is up, we use IP encapsulated BFD (no L2 encap required) > with either unicast or multicast addressing scheme. > >> > >> This solution however requires LACP to work in tandem with the micro > BFD sessions for the LAG. This will work for all scenarios except the > one where a provider does NOT want to run LACP on the LAG (and I am not > sure why somebody would NOT want LACP btw). > >> > >> Cheers, Manav > >> > >>> -----Original Message----- > >>> From: Nitin Bahadur [mailto:nitinb@juniper.net] > >>> Sent: Friday, December 23, 2011 1:29 AM > >>> To: Nitin Bahadur; Bhatia, Manav (Manav); Jeff Tantsura; > >>> rtg-bfd@ietf.org > >>> Subject: Re: BFD on LAG interfaces > >>> > >>> > >>> And just to clarify a little bit more.... > >>> > >>> I don't want BFD to replace LACP. I want it to supplement > >>> LACP. Just like today if we run BFD for OSPF adjacencies, we > >>> don't get rid of OSPF hellos... > >>> But if the BFD session goes down, we tell OSPF about it and > >>> OSPF reacts to that. Similarly (pardon my lack of knowledge > >>> about LACP), LACP can react to BFD member sessions down. The > >>> link can be brought up by LACP at a slower interval. The goal > >>> should be fast failure detection and not necessarily fast > >>> Link-up following a failure correction. > >>> > >>> Thanks > >>> Nitin > >>> > >> > >> This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform > us by e-mail, phone or fax, and then delete the original and all copies > thereof. > >> > > > > > > > > -- > > Toms. > > >=20 > -- > Marc Binderberger