From jeff.tantsura@ericsson.com Tue Jan 3 00:43:00 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB72B21F8599 for ; Tue, 3 Jan 2012 00:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 lqIpVig2eBEd for ; Tue, 3 Jan 2012 00:42:59 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id BC1B821F8598 for ; Tue, 3 Jan 2012 00:42:59 -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 q038gZc3016419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jan 2012 02:42:52 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 3 Jan 2012 03:42:43 -0500 From: Jeff Tantsura To: "Nobo Akiya (nobo)" , Marc Binderberger , Alexander Vainshtein , Tom Sanders Date: Tue, 3 Jan 2012 03:42:40 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: AczGTqL08fyS8yFsRPuFIErgvZ0LnAAOZQ7wANkhHtA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C653351@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> <53895367-8D87-4492-9D19-64FCC5488476@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 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:43:00 -0000 Hi, Let's not make things too complicated :) IMHO: >From RIB point of view - it doesn't care how many links are in the LAG, as= long as its neighbor is reachable (BFD) and min-link has not been met - LA= G is UP from RIB (and its clients) point of view and hence forwarding shoul= d use it. If min-link has been met indeed - RIB doesn't care about reachability anymo= re, from its point of view - LAG is DOWN which is communicated to FP && eve= ry client registered. Having implemented both single and multi session BFD over LAG I can tell yo= u - customers (at least ours :)) don't care about running LACP in addition = to BFD. Logical explanation why it is needed works just fine.I'd be really interes= ted to hear differently. So let me try to go thru the scenario below. LAG UP Before physical layer first and then 802.1ax agree that LAG is UP, RIB does= n't get bothered at all, so no forwarding lookup could possibly yield that= LAG as an outgoing interface and hence no blackholing. Nobo - normally static is as client of RIB as any other protocol interested= in BFD state, it shouldn't care about 802.1ax, as long as RIB doesn't tell= it. Additional link UP Don't care (SS)/span additional BFD session (MS) LINK DOWN single session over LAG (could be LoS or BFD if the link in question is by = chance the same link BFD got hashed over) if=20 min-link not met then ignore else bring LAG DOWN && notify CP (RIB) && notify FP (initiate FRR/etc) multi session BFD over LAG (will be LoS or BFD associated with this particu= lar LAG constituent) same logic as before My 0.2 Regards, Jeff -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Nobo Akiya (nobo) Sent: Thursday, December 29, 2011 4:33 PM To: Marc Binderberger; Alexander Vainshtein; Tom Sanders Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG interfaces Hello Marc, et al, > The problem is to bring up the link with protocol P1 but bring it down=20 > with protocol P2. The underlying assumption is that P1 is interrupted=20 > as well when P2 goes down. True for a clean link cut, questionable if=20 > something goes wrong with the layer-3 alone. Then P1 (LACP or L1) may=20 > 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, th= en 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 th= e 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 an= d 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 is= sue is something "we can live this". Regards, Nobo > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > 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=20 > be planned as a booster for the detection. And keep it simple. On the=20 > 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=20 > with protocol P2. The underlying assumption is that P1 is interrupted=20 > as well when P2 goes down. True for a clean link cut, questionable if=20 > something goes wrong with the layer-3 alone. Then P1 (LACP or L1) may=20 > 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=20 > above situation by either: >=20 > (i) use BFD to control - alone or in combination with LACP - the port=20 > 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=20 > > 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=20 > > 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=20 > 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=20 > 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;=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.=20 > >>> Just like today if we run BFD for OSPF adjacencies, we don't get=20 > >>> rid of 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=20 > >>> LACP), LACP can react to BFD member sessions down. The link can be=20 > >>> brought up by LACP at a slower interval. The goal should be fast=20 > >>> failure detection and not necessarily fast Link-up following a=20 > >>> 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=20 > 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 From Alexander.Vainshtein@ecitele.com Tue Jan 3 01:25:38 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B7C21F8496 for ; Tue, 3 Jan 2012 01:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=-0.372, 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 QStCPc1KJi7P for ; Tue, 3 Jan 2012 01:25:36 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id D989121F847C for ; Tue, 3 Jan 2012 01:25:35 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-182.messagelabs.com!1325582731!8855672!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 20869 invoked from network); 3 Jan 2012 09:25:33 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-13.tower-182.messagelabs.com with SMTP; 3 Jan 2012 09:25:33 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-d1-4f02ca889c44 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 8C.76.08306.88AC20F4; Tue, 3 Jan 2012 11:29:44 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 3 Jan 2012 11:25:32 +0200 From: Alexander Vainshtein To: Jeff Tantsura Date: Tue, 3 Jan 2012 11:25:31 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: AczGTqL08fyS8yFsRPuFIErgvZ0LnAAOZQ7wANkhHtAAAyG8AA== Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> <53895367-8D87-4492-9D19-64FCC5488476@sniff.de> <0ED867EB33AB2B45AAB470D5A64CDBF6181C653351@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C653351@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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupil+LIzCtJLcpLzFFi42KZ/OrTF92OU0z+Bm/Py1tMuX+c1WL2lf/M FrM74i0+/9nGaHH100omB1aPKb83snr8+nqVzWPnrLvsHkuW/GTyaF3dzRLAGtXAaJOYl5df kliSqpCSWpxsqxRQlFmWmFyppJCZYqtkqKRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLz FFLzkvNTMvPSbZU8g/11LSxMLXUNlezUlA2NrblCMjKLFVJ1cxMzcxRyU4uLE9NTFYAiCVuY M25/bWQtuOdTMeuCcwPjROsuRk4OCQETiUsHfjBB2GISF+6tZwOxhQR2Mkrc6lHuYuQCsicz SvxsO8QMkmATsJXYtPouWJGIgJ7Evj+drCBFzAJzGCV2bW8CKuLgYBFQkbi4QxqkRlhASWLV hF/sEPXKEtvv3meEsJ0k5u9bzghSzisQKHF5mzrEri/MEov3v2IFqeEUiJDYsnsXmM0IdNz3 U2vADmUWEJe49WQ+1NECEkv2nGeGsEUlXj7+B1UvKnGnfT0jRL2OxILdn9ggbG2JZQtfg9Xz CghKnJz5hAWiV1Li4IobLBMYxWchWTELSfssJO2zkLQvYGRZxSiZmVNQkpSbbmCkm19aopea nFmSmpOql5yfu4kRkoZe7GC8fUbzEKMAB6MSD6/VA0Z/IdbEsuLK3EOMkhxMSqK8qseY/IX4 kvJTKjMSizPii0pzUosPMUpwMCuJ8ArtA8rxpiRWVqUW5cOkLIABPZFZijs5H5ha80rijQ0M UDhK4rzdyW98hQTSgekuOzW1ILUIplWGg0NJgvfACaCpgkWp6akVaZk5JQhpJg5OkM08QJs/ gdTwFhck5hZnpkPkTzEac9zYt+EsI8eWy5vPMgqx5OXnpUqJ83KcBCoVACnNKM2DmwbKQvX/ //9/xSgO9Lkw7yuQgTzADAY37xXQKiagVbv2gK0C5hK4lFQDo7ZbmLQso8gRbo8a8wi99ITZ qd8ZpjQ1icj7X9SOKPl6fPXFKa7xxdPbp4rsWWFvklrS5aopED/xlh6nzcXVkTdnWk2IvxRp 8aXKpt44JHx219EjJbPn5uxxiC/UW/CKPfaIa3fZOumFy/bf1baYv/qhhN3DT17NpvazyrI+ XIyzue7x9Os7JZbijERDLeai4kQArTkbhR0EAAA= Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:25:38 -0000 Jeff, You've said " customers (at least ours :)) don't care about running LACP in= addition to BFD". Does "don't care" here mean that do not mind running both, or object to run= ning both? A clarification on that point seems important. Regards, Sasha > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Tuesday, January 03, 2012 10:43 AM > To: Nobo Akiya (nobo); Marc Binderberger; Alexander Vainshtein; Tom > Sanders > Cc: rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces > > Hi, > > Let's not make things too complicated :) > > IMHO: > From RIB point of view - it doesn't care how many links are in the LAG, a= s > long as its neighbor is reachable (BFD) and min-link has not been met - LA= G > is UP from RIB (and its clients) point of view and hence forwarding should > use it. > If min-link has been met indeed - RIB doesn't care about reachability > anymore, from its point of view - LAG is DOWN which is communicated to FP > && every client registered. > > Having implemented both single and multi session BFD over LAG I can tell > you - customers (at least ours :)) don't care about running LACP in additi= on > to BFD. > Logical explanation why it is needed works just fine.I'd be really intere= sted > to hear differently. > > So let me try to go thru the scenario below. > LAG UP > Before physical layer first and then 802.1ax agree that LAG is UP, RIB doe= sn't > get bothered at all, so no forwarding lookup could possibly yield that LA= G as > an outgoing interface and hence no blackholing. > Nobo - normally static is as client of RIB as any other protocol intereste= d in > BFD state, it shouldn't care about 802.1ax, as long as RIB doesn't tell it= . > > Additional link UP > Don't care (SS)/span additional BFD session (MS) > > LINK DOWN > single session over LAG (could be LoS or BFD if the link in question is by > chance the same link BFD got hashed over) > > if > min-link not met > then ignore > else > bring LAG DOWN && notify CP (RIB) && notify FP (initiate FRR/etc) > > > multi session BFD over LAG (will be LoS or BFD associated with this > particular LAG constituent) > same logic as before > > My 0.2 > > Regards, > Jeff > > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Nobo Akiya (nobo) > Sent: Thursday, December 29, 2011 4:33 PM > To: Marc Binderberger; Alexander Vainshtein; Tom Sanders > Cc: rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces > > 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. > > > > 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 tim= e > out (and stop using the link) eventually? If we want to keep it simple, th= en > 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 t= he > 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 blackho= led. > (2) Static route, once 802.1ax state is up, will install route over it, bu= t 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 > > > > 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, > > > > > > 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. > > > > > > > -- > > 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 jeff.tantsura@ericsson.com Tue Jan 3 01:41:43 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5823721F8484 for ; Tue, 3 Jan 2012 01:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 X6B5hATwz8dh for ; Tue, 3 Jan 2012 01:41:42 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 150A121F84C3 for ; Tue, 3 Jan 2012 01:41:42 -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 q039faFf017291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jan 2012 03:41:37 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 3 Jan 2012 04:41:36 -0500 From: Jeff Tantsura To: Alexander Vainshtein Date: Tue, 3 Jan 2012 04:41:34 -0500 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: AczGTqL08fyS8yFsRPuFIErgvZ0LnAAOZQ7wANkhHtAAAyG8AAAAKepg Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF6181C653352@EUSAACMS0701.eamcs.ericsson.se> References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> <53895367-8D87-4492-9D19-64FCC5488476@sniff.de> <0ED867EB33AB2B45AAB470D5A64CDBF6181C653351@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 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:41:43 -0000 Hi Sasha, The first, running both. They'd run LACP anyway even before BFD over LAG ha= d become available, there's no benefit is disabling it after. In my past, for over 10 years I used to do network architecture and design = in multivendor environment, to my memory the only case one wouldn't use LAC= P was either lack of support (oldish Cisco gear) or extremely buggy impleme= ntations (no names here :)) Again - I'm talking for myself and my customers, some might not like it for= whatever reasons... P.S. Dear BFDers - Happy New Year! Regards, Jeff P.S. Dear BFDers - Happy New Year! -----Original Message----- From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]=20 Sent: Tuesday, January 03, 2012 1:26 AM To: Jeff Tantsura Cc: rtg-bfd@ietf.org; Nobo Akiya (nobo); Marc Binderberger; Tom Sanders Subject: RE: BFD on LAG interfaces Jeff, You've said " customers (at least ours :)) don't care about running LACP in= addition to BFD". Does "don't care" here mean that do not mind running both, or object to ru= nning both? A clarification on that point seems important. Regards, Sasha > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Tuesday, January 03, 2012 10:43 AM > To: Nobo Akiya (nobo); Marc Binderberger; Alexander Vainshtein; Tom=20 > Sanders > Cc: rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces >=20 > Hi, >=20 > Let's not make things too complicated :) >=20 > IMHO: > From RIB point of view - it doesn't care how many links are in the=20 > LAG, as long as its neighbor is reachable (BFD) and min-link has not=20 > been met - LAG is UP from RIB (and its clients) point of view and=20 > hence forwarding should use it. > If min-link has been met indeed - RIB doesn't care about reachability=20 > anymore, from its point of view - LAG is DOWN which is communicated to=20 > FP && every client registered. >=20 > Having implemented both single and multi session BFD over LAG I can=20 > tell you - customers (at least ours :)) don't care about running LACP=20 > in addition to BFD. > Logical explanation why it is needed works just fine.I'd be really=20 > interested to hear differently. >=20 > So let me try to go thru the scenario below. > LAG UP > Before physical layer first and then 802.1ax agree that LAG is UP, RIB=20 > doesn't get bothered at all, so no forwarding lookup could possibly=20 > yield that LAG as an outgoing interface and hence no blackholing. > Nobo - normally static is as client of RIB as any other protocol=20 > interested in BFD state, it shouldn't care about 802.1ax, as long as RIB = doesn't tell it. >=20 > Additional link UP > Don't care (SS)/span additional BFD session (MS) >=20 > LINK DOWN > single session over LAG (could be LoS or BFD if the link in question=20 > is by chance the same link BFD got hashed over) >=20 > if > min-link not met > then ignore > else > bring LAG DOWN && notify CP (RIB) && notify FP (initiate FRR/etc) >=20 >=20 > multi session BFD over LAG (will be LoS or BFD associated with this=20 > particular LAG constituent) same logic as before >=20 > My 0.2 >=20 > Regards, > Jeff >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > Behalf Of Nobo Akiya (nobo) > Sent: Thursday, December 29, 2011 4:33 PM > To: Marc Binderberger; Alexander Vainshtein; Tom Sanders > Cc: rtg-bfd@ietf.org > Subject: RE: BFD on LAG interfaces >=20 > Hello Marc, et al, >=20 > > The problem is to bring up the link with protocol P1 but bring it=20 > > down with protocol P2. The underlying assumption is that P1 is=20 > > interrupted as well when P2 goes down. True for a clean link cut,=20 > > questionable if something goes wrong with the layer-3 alone. Then P1=20 > > (LACP or L1) may be up and thus the LAG port is active while P2 (BFD) s= tays down. > > > > Maybe we can live with it (?). >=20 > "Can we live with it" is indeed the primary question. If consensus is=20 > yes, then secondary question becomes what action should LMM take (if=20 > any at all)? LMM will know P1 is up but P2 has not come up for "long" tim= e: > hours or even days. Should LMM continue to use such link, or should it=20 > time out (and stop using the link) eventually? If we want to keep it=20 > simple, then the answer here would be "no timeout mechanism" here as well= . >=20 > > Maybe someone has implemented the "P1 brings up, P2 brings down" and > can > > talk about the experience? >=20 > I'm curious on this. Side effect here is traffic blackhole. To=20 > 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=20 > come up due to layer-3 specific failure. Let's label this link L1. >=20 > (1) Routing protocols "handshake" happens to take place over non-L1=20 > link and traffic shifts over 802.1ax, but traffic going over L1 will be b= lackholed. > (2) Static route, once 802.1ax state is up, will install route over=20 > it, but traffic going over L1 will be blackholed. >=20 > Certainly would like to hear input from vendors if someone has=20 > implemented this model, but would also like to hear from operators if=20 > this potential issue is something "we can live this". >=20 > Regards, > Nobo >=20 > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On=20 > > 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 > > > > Hello Tom, Alexander et al., > > > > in general I agree with your statements. BFD is _not_ LACP. BFD=20 > > should be planned as a booster for the detection. And keep it=20 > > 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=20 > > down with protocol P2. The underlying assumption is that P1 is=20 > > interrupted as well when P2 goes down. True for a clean link cut,=20 > > questionable if something goes wrong with the layer-3 alone. Then P1=20 > > (LACP or L1) may be up and thus the LAG port is active while P2 (BFD) s= tays down. > > > > Maybe we can live with it (?). > > > > > > As far as I know about existing implementations they seem to avoid=20 > > the above situation by either: > > > > (i) use BFD to control - alone or in combination with LACP - the=20 > > 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, > > > > > > 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=20 > > > 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=20 > > > wrote: > > >> Manav, > > >> The scheme you've presented looks OK to me. > > >> > > >> Regarding your question - why somebody would NOT want LACP - I=20 > > >> can > > only add that micro-BFD sessions, in my opinion, are used to replace=20 > > 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=20 > > >> can > > give:-) > > >> > > >> Regards, > > >> Sasha > > >> > > >> ________________________________________ > > >> From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On=20 > > >> 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=20 > > the one where a provider does NOT want to run LACP on the LAG (and I=20 > > 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;=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 like today if we run BFD for OSPF adjacencies, we don't get=20 > > >>> rid of 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=20 > > >>> LACP), LACP can react to BFD member sessions down. The link can=20 > > >>> be brought up by LACP at a slower interval. The goal should be=20 > > >>> fast failure detection and not necessarily fast Link-up=20 > > >>> following a failure correction. > > >>> > > >>> Thanks > > >>> Nitin > > >>> > > >> > > >> This e-mail message is intended for the recipient only and=20 > > >> contains > > information which is CONFIDENTIAL and which may be proprietary to=20 > > 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. > > > > > > > -- > > Marc Binderberger 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 Tue Jan 3 02:41:16 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3521F84B4 for ; Tue, 3 Jan 2012 02:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=-0.298, 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 jfF-MPK2eUmh for ; Tue, 3 Jan 2012 02:41:15 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 0962421F84C8 for ; Tue, 3 Jan 2012 02:41:14 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-216.messagelabs.com!1325587267!9526588!4 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 3704 invoked from network); 3 Jan 2012 10:41:12 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-12.tower-216.messagelabs.com with SMTP; 3 Jan 2012 10:41:12 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-1b-4f02dc426bd5 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 0C.88.08306.24CD20F4; Tue, 3 Jan 2012 12:45:22 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Tue, 3 Jan 2012 12:41:10 +0200 From: Alexander Vainshtein To: Jeff Tantsura Date: Tue, 3 Jan 2012 12:41:09 +0200 Subject: RE: BFD on LAG interfaces Thread-Topic: BFD on LAG interfaces Thread-Index: AczGTqL08fyS8yFsRPuFIErgvZ0LnAAOZQ7wANkhHtAAAyG8AAAAKepgAAKMcLA= Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com> <53895367-8D87-4492-9D19-64FCC5488476@sniff.de> <0ED867EB33AB2B45AAB470D5A64CDBF6181C653351@EUSAACMS0701.eamcs.ericsson.se> <0ED867EB33AB2B45AAB470D5A64CDBF6181C653352@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <0ED867EB33AB2B45AAB470D5A64CDBF6181C653352@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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjl+LIzCtJLcpLzFFi42KZ/OrTF12nO0z+Bh3PLCym3D/OajH7yn9m i9kd8Raf/2xjtLj6aSWTA6vHlN8bWT1+fb3K5rFz1l12jyVLfjJ5tK7uZglgjWpgtEnMy8sv SSxJVUhJLU62VQooyixLTK5UUshMsVUyVFIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5 Cql5yfkpmXnptkqewf66FhamlrqGSnZqyobG1lwhGZnFCqm6uYmZOQq5qcXFiempCkCRhC3M GT+atrEXnIqt+HTjIHsD42L3LkZODgkBE4llF/cwQthiEhfurWfrYuTiEBLYySix4FgLE4Qz mVFi27E1zCBVbAK2EptW32UDsUUE9CT2/elkBSliFpjDKLFrexNYEYuAisTcm79ZQGxhASWJ VRN+sUM0KEtsv3ufEcL2k/j/5jJYDa9AoMTGow1Q27pYJS4+amUCSXAKREgc6JkCto0R6L7v p9aAxZkFxCVuPZnPBHG3gMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhRryOxYPcnNghbW2LZwtfM EIsFJU7OfMIC0SspcXDFDZYJjOKzkKyYhaR9FpL2WUjaFzCyrGKUzMwpKEnKTTcw0s0vLdFL Tc4sSc1J1UvOz93ECElHL3Yw3j6jeYhRgINRiYfX6gGjvxBrYllxZe4hRkkOJiVR3sUXmfyF +JLyUyozEosz4otKc1KLDzFKcDArifAK7QPK8aYkVlalFuXDpCyAQT2RWYo7OR+YYvNK4o0N DFA4SuK83clvfIUE0oFpLzs1tSC1CKZVhoNDSYK36xbQVMGi1PTUirTMnBKENBMHJ8hmHqDN jSA1vMUFibnFmekQ+VOMxhw39m04y8ix5fLms4xCLHn5ealS4rzpIKUCIKUZpXlw00DZqP7/ //+vGMWBPhfm3QxSxQPMZHDzXgGtYgJatWsP2CpgToFLSTUwMjz5niifvmz5P7d2+6D0/i9b L2/inqC9UfNqqFRgNMfeRU2dtZ1enQl2fyT9pTdcyzg+69IF9slqKinV941X755hPzl4npRe 0ZknpWIVu7/36X5rubTb/eyKkxp6TbE5AbELaxrFwmZfP/GjyGMa+86V3lpnVycnsj1/wH9j Zd5RnxOFIoEySizFGYmGWsxFxYkAluqpoSEEAAA= Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 10:41:16 -0000 Jeff, Lots of thanks for a prompt and unambiguous response! Happy New year to all! Regards, Sasha > -----Original Message----- > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > Sent: Tuesday, January 03, 2012 11:42 AM > To: Alexander Vainshtein > Cc: rtg-bfd@ietf.org; Nobo Akiya (nobo); Marc Binderberger; Tom Sanders > Subject: RE: BFD on LAG interfaces > > Hi Sasha, > > The first, running both. They'd run LACP anyway even before BFD over LAG > had become available, there's no benefit is disabling it after. > In my past, for over 10 years I used to do network architecture and design= in > multivendor environment, to my memory the only case one wouldn't use > LACP was either lack of support (oldish Cisco gear) or extremely buggy > implementations (no names here :)) > > Again - I'm talking for myself and my customers, some might not like it fo= r > whatever reasons... > > P.S. Dear BFDers - Happy New Year! > > Regards, > Jeff > > P.S. Dear BFDers - Happy New Year! > > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, January 03, 2012 1:26 AM > To: Jeff Tantsura > Cc: rtg-bfd@ietf.org; Nobo Akiya (nobo); Marc Binderberger; Tom Sanders > Subject: RE: BFD on LAG interfaces > > Jeff, > You've said " customers (at least ours :)) don't care about running LACP i= n > addition to BFD". > > Does "don't care" here mean that do not mind running both, or object to > running both? A clarification on that point seems important. > > Regards, > Sasha > > > -----Original Message----- > > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > > Sent: Tuesday, January 03, 2012 10:43 AM > > To: Nobo Akiya (nobo); Marc Binderberger; Alexander Vainshtein; Tom > > Sanders > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD on LAG interfaces > > > > Hi, > > > > Let's not make things too complicated :) > > > > IMHO: > > From RIB point of view - it doesn't care how many links are in the > > LAG, as long as its neighbor is reachable (BFD) and min-link has not > > been met - LAG is UP from RIB (and its clients) point of view and > > hence forwarding should use it. > > If min-link has been met indeed - RIB doesn't care about reachability > > anymore, from its point of view - LAG is DOWN which is communicated to > > FP && every client registered. > > > > Having implemented both single and multi session BFD over LAG I can > > tell you - customers (at least ours :)) don't care about running LACP > > in addition to BFD. > > Logical explanation why it is needed works just fine.I'd be really > > interested to hear differently. > > > > So let me try to go thru the scenario below. > > LAG UP > > Before physical layer first and then 802.1ax agree that LAG is UP, RIB > > doesn't get bothered at all, so no forwarding lookup could possibly > > yield that LAG as an outgoing interface and hence no blackholing. > > Nobo - normally static is as client of RIB as any other protocol > > interested in BFD state, it shouldn't care about 802.1ax, as long as RIB > doesn't tell it. > > > > Additional link UP > > Don't care (SS)/span additional BFD session (MS) > > > > LINK DOWN > > single session over LAG (could be LoS or BFD if the link in question > > is by chance the same link BFD got hashed over) > > > > if > > min-link not met > > then ignore > > else > > bring LAG DOWN && notify CP (RIB) && notify FP (initiate FRR/etc) > > > > > > multi session BFD over LAG (will be LoS or BFD associated with this > > particular LAG constituent) same logic as before > > > > My 0.2 > > > > Regards, > > Jeff > > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > Behalf Of Nobo Akiya (nobo) > > Sent: Thursday, December 29, 2011 4:33 PM > > To: Marc Binderberger; Alexander Vainshtein; Tom Sanders > > Cc: rtg-bfd@ietf.org > > Subject: RE: BFD on LAG interfaces > > > > 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. > > > > > > 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" ti= me: > > 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 > > > > > > 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, > > > > > > > > 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. > > > > > > > > > > -- > > > Marc Binderberger > > > > 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. 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 Tue Jan 3 17:19:30 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3E11E80C1 for ; Tue, 3 Jan 2012 17:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 QCL-yVH6ef91 for ; Tue, 3 Jan 2012 17:19:29 -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 2F1A511E80BF for ; Tue, 3 Jan 2012 17:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nobo@cisco.com; l=14085; q=dns/txt; s=iport; t=1325639969; x=1326849569; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1hh/QZQgZ5WEUr3xc8np0Ec8zNykDp8mxJcS2hCcO6w=; b=FueFZ++oOojAOWUO3K3XZQnFbora9qJuJ6xpPxmAkBDbeUuzLk6t+IH8 QwSTYuG2HHGA0VfM4vD8zWEbH5f+qkDePKRlbbPOxjcVgrKlS9pRYMg/J qxbcuD+gRWoWjKB3PfAwi9obCiz4CjKgacuB0XQC9adSxOtFKDN26+QUu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAAC6oA0+rRDoG/2dsb2JhbABDggWaHJBBgQWBcgEBAQMBEgEdCj8MBAIBCBEBAwEBAQoGFwEGAUUDBggCBAESCBMHh1iXQQGeGossYwSIN58g X-IronPort-AV: E=Sophos;i="4.71,453,1320624000"; d="scan'208";a="23673369" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 04 Jan 2012 01:19:28 +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 q041JSoH017686; Wed, 4 Jan 2012 01:19:28 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); Tue, 3 Jan 2012 17:19:28 -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: Tue, 3 Jan 2012 17:19:25 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD on LAG interfaces Thread-Index: AczGTqL08fyS8yFsRPuFIErgvZ0LnAAOZQ7wANkhHtAAAyG8AAAAKepgAAKMcLAAHjh+0A== References: <7C362EEF9C7896468B36C9B79200D8350D027BAE84@INBANSXCHMBSA1.in.alcatel-lucent.com><53895367-8D87-4492-9D19-64FCC5488476@sniff.de> <0ED867EB33AB2B45AAB470D5A64CDBF6181C653351@EUSAACMS0701.eamcs.ericsson.se> <0ED867EB33AB2B45AAB470D5A64CDBF6181C653352@EUSAACMS0701.eamcs.ericsson.se> From: "Nobo Akiya (nobo)" To: "Alexander Vainshtein" , "Jeff Tantsura" X-OriginalArrivalTime: 04 Jan 2012 01:19:28.0371 (UTC) FILETIME=[E7646C30:01CCCA7E] 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, 04 Jan 2012 01:19:30 -0000 Happy new year to everyone on the list ;) Jeff, et al, I agree with your statements on "RIB point of view", a link will get used if it's "blessed". However, my concern is in the asymmetric "blessing" logic described in this email. Below were stated. >> 1. We use LACP to bring up the links. >> So, we use BFD only to bring down the link. This can create severe traffic impacting scenario if a system ever falls into a scenario where BFD fails but LACP continues to work (ex: L3 specific failure). IMHO, if BFD is used to bring down the link, then it should be used to bring up the link as well. With this logic, dependency to LACP is no longer required either. I'd be curious to see what other folks thinks on this. Regards, Nobo > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Tuesday, January 03, 2012 7:41 PM > To: Jeff Tantsura > Cc: rtg-bfd@ietf.org; Nobo Akiya (nobo); Marc Binderberger; Tom Sanders > Subject: RE: BFD on LAG interfaces >=20 > Jeff, > Lots of thanks for a prompt and unambiguous response! >=20 > Happy New year to all! >=20 > Regards, > Sasha >=20 >=20 > > -----Original Message----- > > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > > Sent: Tuesday, January 03, 2012 11:42 AM > > To: Alexander Vainshtein > > Cc: rtg-bfd@ietf.org; Nobo Akiya (nobo); Marc Binderberger; Tom Sanders > > Subject: RE: BFD on LAG interfaces > > > > Hi Sasha, > > > > The first, running both. They'd run LACP anyway even before BFD over > LAG > > had become available, there's no benefit is disabling it after. > > In my past, for over 10 years I used to do network architecture and > design in > > multivendor environment, to my memory the only case one wouldn't use > > LACP was either lack of support (oldish Cisco gear) or extremely buggy > > implementations (no names here :)) > > > > Again - I'm talking for myself and my customers, some might not like > it for > > whatever reasons... > > > > P.S. Dear BFDers - Happy New Year! > > > > Regards, > > Jeff > > > > P.S. Dear BFDers - Happy New Year! > > > > -----Original Message----- > > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > > Sent: Tuesday, January 03, 2012 1:26 AM > > To: Jeff Tantsura > > Cc: rtg-bfd@ietf.org; Nobo Akiya (nobo); Marc Binderberger; Tom Sanders > > Subject: RE: BFD on LAG interfaces > > > > Jeff, > > You've said " customers (at least ours :)) don't care about running > LACP in > > addition to BFD". > > > > Does "don't care" here mean that do not mind running both, or object > to > > running both? A clarification on that point seems important. > > > > Regards, > > Sasha > > > > > -----Original Message----- > > > From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] > > > Sent: Tuesday, January 03, 2012 10:43 AM > > > To: Nobo Akiya (nobo); Marc Binderberger; Alexander Vainshtein; Tom > > > Sanders > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: BFD on LAG interfaces > > > > > > Hi, > > > > > > Let's not make things too complicated :) > > > > > > IMHO: > > > From RIB point of view - it doesn't care how many links are in the > > > LAG, as long as its neighbor is reachable (BFD) and min-link has not > > > been met - LAG is UP from RIB (and its clients) point of view and > > > hence forwarding should use it. > > > If min-link has been met indeed - RIB doesn't care about reachability > > > anymore, from its point of view - LAG is DOWN which is communicated > to > > > FP && every client registered. > > > > > > Having implemented both single and multi session BFD over LAG I can > > > tell you - customers (at least ours :)) don't care about running LACP > > > in addition to BFD. > > > Logical explanation why it is needed works just fine.I'd be really > > > interested to hear differently. > > > > > > So let me try to go thru the scenario below. > > > LAG UP > > > Before physical layer first and then 802.1ax agree that LAG is UP, > RIB > > > doesn't get bothered at all, so no forwarding lookup could possibly > > > yield that LAG as an outgoing interface and hence no blackholing. > > > Nobo - normally static is as client of RIB as any other protocol > > > interested in BFD state, it shouldn't care about 802.1ax, as long > as RIB > > doesn't tell it. > > > > > > Additional link UP > > > Don't care (SS)/span additional BFD session (MS) > > > > > > LINK DOWN > > > single session over LAG (could be LoS or BFD if the link in question > > > is by chance the same link BFD got hashed over) > > > > > > if > > > min-link not met > > > then ignore > > > else > > > bring LAG DOWN && notify CP (RIB) && notify FP (initiate FRR/etc) > > > > > > > > > multi session BFD over LAG (will be LoS or BFD associated with this > > > particular LAG constituent) same logic as before > > > > > > My 0.2 > > > > > > Regards, > > > Jeff > > > > > > -----Original Message----- > > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > > > Behalf Of Nobo Akiya (nobo) > > > Sent: Thursday, December 29, 2011 4:33 PM > > > To: Marc Binderberger; Alexander Vainshtein; Tom Sanders > > > Cc: rtg-bfd@ietf.org > > > Subject: RE: BFD on LAG interfaces > > > > > > 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. > > > > > > > > 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 > > > > > > > > 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, > > > > > > > > > > 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. > > > > > > > > > > > > > -- > > > > Marc Binderberger > > > > > > > > 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 > 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. From pabloisnot@gmail.com Wed Jan 4 08:12:16 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FF421F8746 for ; Wed, 4 Jan 2012 08:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=1.855, 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 hb6gu18YClMe for ; Wed, 4 Jan 2012 08:12:16 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 321DF21F86C2 for ; Wed, 4 Jan 2012 08:12:16 -0800 (PST) Received: by obcuz6 with SMTP id uz6so16082714obc.31 for ; Wed, 04 Jan 2012 08:12:15 -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; bh=y/JI8ifEGq57iqkXIsrYK+gTs0HtbRseQ4J6MCgS8BE=; b=p1TiddZcPO8fZxnJ7u2NPUDsGU612+CdDLLoZrTxn6gVOfN0Suef9HPIxHV8BJr/XF F5HLQmENb6DH2Gp2lE0lcVhgnjgrQK2K6cuIUm6OLxA7tbJvHjrnxFReGMJmwFFmWipv fYTx/19P/2x3bILT4THHQDoQ6Oud8V5gGIdpg= MIME-Version: 1.0 Received: by 10.182.113.3 with SMTP id iu3mr25897596obb.78.1325693535802; Wed, 04 Jan 2012 08:12:15 -0800 (PST) Received: by 10.182.51.165 with HTTP; Wed, 4 Jan 2012 08:12:12 -0800 (PST) Date: Wed, 4 Jan 2012 11:12:13 -0500 Message-ID: Subject: re: Multicast vs Unicast (was BFD on LAG interfaces) From: Pablo Frank To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:12:17 -0000 I know there's been some arguments made in favour of option 1 that suggest that existing ASICs may be better able to handle IP-encapsulated BFD. Frankly, most vendors are using flexible-enough parsing hardware so I'm not sure this is a very strong argument anymore. So I decided to focus on just looking at it from a pure software IP-stack perspective. It seems that either variant of option 1 requires an implementer to do some pretty ugly hacking to get around existing stack implementations. I tried getting 1a to work using standard Linux socket APIs and ran into all sorts of problems. The fundamental issue is that the member links of a LAG are not normally IP-enabled so trying to bind an IP multicast group membership didn't work. The other issue was trying to force the UDP frames out a particular underlying member link was not possible using the existing socket options for UDP sockets. The only way I got it to work was using AF_PACKET raw sockets and setting up some Berkeley Packet Filters to filter out the frames with the correct L2 multicast MAC address, ethertype, and L3 multicast IP address (since L2 multicast address is not specific enough). But in this case, I'm essentially bypassing the IP stack so I don't get to benefit-from/reuse any of the normal IP stack capabilities (i.e. no IP header validation, checksum checking, etc.). This was really ugly. I didn't even try 1b. Option 2, on the other hand, was trivially easy using AF_PACKET DGRAM sockets. It was very straightforward to bind the TBA ethertype, the TBA multicast MAC, and the interface to use. The fact that option 1 was so convoluted isn't surprising given the obvious layering violations that are taking place here. So unless there are gigantic barriers in place to prevent us from getting a MAC address and ethertype assigned for this kind of low-level BFD, I don't think we should really be seriously considering either variant of option 1. regards, Pablo > 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 From manav.bhatia@alcatel-lucent.com Thu Jan 5 18:36:17 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6EE121F8790 for ; Thu, 5 Jan 2012 18:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 zXtDGVIkJDyt for ; Thu, 5 Jan 2012 18:36:17 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5767621F8736 for ; Thu, 5 Jan 2012 18:36:17 -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 q062aDJG007054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 5 Jan 2012 20:36:16 -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 q062aCEj025224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 6 Jan 2012 08:06:12 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Fri, 6 Jan 2012 08:06:12 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Fri, 6 Jan 2012 08:06:09 +0530 Subject: BFD over LAGs updated - 03 Thread-Topic: BFD over LAGs updated - 03 Thread-Index: AczMG/LRIgYl+1e4RoqSRBorRfjkAg== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2DAB@INBANSXCHMBSA1.in.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 02:36:18 -0000 Hi WG members, We have posted a revised version of the BFD over LAGs draft. Based on the discussions on the list we have also included an option to use= direct L2 encapsulation for sending BFD packets on the micro BFD sessions.= Based on what the WG decides we will need to remove either the IP encapsul= ation or the text about the direct L2 encapsulation since we don't intend t= o support the two approaches.=20 Even within IP, we have two options - using Unicast or Multicast destinatio= n addressing. Again, while we (the authors of the draft) strongly prefer th= e Multicast approach we have also added text describing how we can make Uni= cast work. The draft is available here: http://www.ietf.org/internet-drafts/draft-mmm-bfd-on-lags-02.txt=20 Diff beween the -01 and the -02 version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-mmm-bfd-on-lags-02.txt Would be great if the WG members can review this version and provide their = feedback. Cheers,=20 Marc, Mach and Manav=20 From robrennison@gmail.com Wed Jan 4 12:40:06 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED0C11E80A1 for ; Wed, 4 Jan 2012 12:40:06 -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 fgbI5vfOdDfB for ; Wed, 4 Jan 2012 12:40:05 -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 147EB11E809F for ; Wed, 4 Jan 2012 12:40:04 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so21594526wgb.13 for ; Wed, 04 Jan 2012 12:40:04 -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=DQWsb6XiFjKaXLknsyLs8lkHwccxK7O6dmnOSmlwWHs=; b=u8dN+mos7hL0BLJyuaI/lxppj25/QzODjnLDrgnuHYuC+cUCHzxUcVnEYVg3CSnKSM cekZN0+/oh8X7L0wo2+zohAufLZs8eLFvlFBqsqQxxr2Jw4SmnlNcw7gARsndEZnFmQN 7FcfLGaYUKNlVbTdBPz7nwFuGDF/U3ySJpnH8= Received: by 10.227.204.130 with SMTP id fm2mr14181838wbb.13.1325709604115; Wed, 04 Jan 2012 12:40:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.95.69 with HTTP; Wed, 4 Jan 2012 12:39:43 -0800 (PST) In-Reply-To: References: From: Robert Rennison Date: Wed, 4 Jan 2012 15:39:43 -0500 Message-ID: Subject: Re: Multicast vs Unicast (was BFD on LAG interfaces) To: Pablo Frank Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 08 Jan 2012 13:22:25 -0800 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, 04 Jan 2012 20:49:44 -0000 Pablo I agree, I am sensing a lot of over-engineering going on in some of the discussions re encapsulations, my gut feel going when I saw the thread start was, it will quickly settle on using a new Ethertype. I lost track of or was never really convinced of what concrete reason folks would want to be using anything other than an L2 encaps, for example the individual links do not have an IP address on them so then there were debates about using IP mcast addresses and demuxing on port , yeuch. So on the K.I.S.S principle my vote goes too for trying to getting a new Ethertype and do not try to get a spec allowing a multiple of encaps as this has the potential to balloon out of all proportion. Cheers Rob Rennison P.s I am also a fan of sticking to having BFD be an adjunct to or an accelerator for LACP so have the micro flow or per interface BFD sessions provide an early indication to LACP that there is a problem with the link. One still potentially needs an overarching slower per LAG group BFD session to keep the upper layers happy if they are expecting BFD on the IP interface. I say potentially because if the interface is now protected by an augmented LACP perhaps the upper layers do not need an explicit BFD, that's a more nuanced discussion. On Wed, Jan 4, 2012 at 11:12 AM, Pablo Frank wrote: > I know there's been some arguments made in favour of option 1 that > suggest that existing ASICs may be better able to handle > IP-encapsulated BFD. =A0Frankly, most vendors are using flexible-enough > parsing hardware so I'm not sure this is a very strong argument > anymore. =A0So I decided to focus on just looking at it from a pure > software IP-stack perspective. > > It seems that either variant of option 1 requires an implementer to do > some pretty ugly hacking to get around existing stack implementations. > =A0I tried getting 1a to work using standard Linux socket APIs and ran > into all sorts of problems. =A0The fundamental issue is that the member > links of a LAG are not normally IP-enabled so trying to bind an IP > multicast group membership didn't work. =A0The other issue was trying to > force the UDP frames out a particular underlying member link was not > possible using the existing socket options for UDP sockets. =A0The only > way I got it to work was using AF_PACKET raw sockets and setting up > some Berkeley Packet Filters to filter out the frames with the correct > L2 multicast MAC address, ethertype, and L3 multicast IP address > (since L2 multicast address is not specific enough). =A0But in this > case, I'm essentially bypassing the IP stack so I don't get to > benefit-from/reuse any of the normal IP stack capabilities (i.e. no IP > header validation, checksum checking, etc.). =A0This was really ugly. =A0= I > didn't even try 1b. > > Option 2, on the other hand, was trivially easy using AF_PACKET DGRAM > sockets. =A0It was very straightforward to bind the TBA ethertype, the > TBA multicast MAC, and the interface to use. > > The fact that option 1 was so convoluted isn't surprising given the > obvious layering violations that are taking place here. =A0So unless > there are gigantic barriers in place to prevent us from getting a MAC > address and ethertype assigned for this kind of low-level BFD, I don't > think we should really be seriously considering either variant of > option 1. > > regards, > Pablo > >> 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 Unicas= t. >> >> 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 From jhaas@slice.pfrc.org Sun Jan 8 15:51:35 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A629621F84C5 for ; Sun, 8 Jan 2012 15:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.612 X-Spam-Level: X-Spam-Status: No, score=-101.612 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnIFcocNlDlH for ; Sun, 8 Jan 2012 15:51:35 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 19EF321F8499 for ; Sun, 8 Jan 2012 15:51:35 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9A3A2224072; Sun, 8 Jan 2012 23:51:23 +0000 (UTC) Date: Sun, 8 Jan 2012 18:51:23 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org, Sam Aldrin Subject: Re: BFD MIB extension for MPLS-TP Message-ID: <20120108235123.GL7464@slice> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: draft-vkst-bfd-mpls-mib@tools.ietf.org, rcallon@juniper.net 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, 08 Jan 2012 23:51:35 -0000 [cc: mpls chairs] Sam, I believe this MIB is in scope for the BFD WG charter: "1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 5. Assist in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification." However, there's also some argument to keep all of the MPLS-TP MIB work together in the MPLS WG. Most of the MPLS-TP work, including MIBs, is occurring in the MPLS WG. Doing a cursory review of the two other drafts you presented in the same session, there is no strong binding from the oam-id or te-mib to the BFD MPLS-TP MIB, but the MPLS-TP BFD MIB has a strong dependency on the oam-id MIB. The MPLS-TP BFD MIB depends on a common index from the bfd session table. Given these dependencies, it seems to make some some sense to keep the MPLS-TP MIB work bundled together in on group. I was not at IETF 82. Per the MPLS WG minutes it sounds like there is some debate as to which WG would cover this work. I personally have no strong preference as to which group is in the draft name since the BFD WG will be providing review, per charter, regardless of which group it is in. With that, I pass the WG adoption token back to the MPLS chairs. We're happy to take on the work if you don't want it. -- Jeff On Thu, Dec 15, 2011 at 08:17:24PM -0800, Sam Aldrin wrote: > 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 From jhaas@slice.pfrc.org Sun Jan 8 16:42:58 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8AE21F85D7 for ; Sun, 8 Jan 2012 16:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.721 X-Spam-Level: X-Spam-Status: No, score=-101.721 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izWXnENnVpuB for ; Sun, 8 Jan 2012 16:42:57 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B6E8821F85D6 for ; Sun, 8 Jan 2012 16:42:57 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 74C18224107; Mon, 9 Jan 2012 00:42:56 +0000 (UTC) Date: Sun, 8 Jan 2012 19:42:56 -0500 From: Jeffrey Haas To: Sam Aldrin Subject: Re: BFD MIB extension for MPLS-TP Message-ID: <20120109004256.GM7464@slice> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: draft-vkst-bfd-mpls-mib@tools.ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 00:42:58 -0000 [Mostly writing as an individual contributor.] On Thu, Dec 15, 2011 at 08:17:24PM -0800, Sam Aldrin wrote: > 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. My first comment is that the object names in this MIB seem to strongly suggest that this is a general extension MIB for BFD rather than are adding MPLS-TP specific objects to the BFD MIB. E.g.: bfdExtObjects bfdSessExtTable etc. I would strongly suggest the object names be more specific in alluding to MPLS-TP. SessionMapTypeTC should similarly note that it is associated with both BFD and MPLS-TP. Also, if there's any chance that this TC will see re-use, it should be placed in its own MIB at some point in the future. IMO, it's fine to leave it in this document for a few iterations for refining the MIB. bfdSessExtTable contains read-create objects but is INDEXed on the BFD session table rather than AUGMENTing it. As such it needs its own RowStatus and StorageType objects. bfdSessExtMapType and bfdSessExtMapPointer should probably get useful DEFVAL entries that install an inactive row if the MIB user inadvertantly do a createAnd* operation. This may suggest that a map type of "none" may be required. -- Jeff From jhaas@slice.pfrc.org Sun Jan 8 18:28:17 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6462421F85E7 for ; Sun, 8 Jan 2012 18:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01TX4yMqIwaz for ; Sun, 8 Jan 2012 18:28:16 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B975021F85D7 for ; Sun, 8 Jan 2012 18:28:16 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 59A0422406C; Mon, 9 Jan 2012 02:28:15 +0000 (UTC) Date: Sun, 8 Jan 2012 21:28:15 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Message-ID: <20120109022815.GN7464@slice> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 02:28:17 -0000 [Speaking currently as an individual contributor.] I believe that Appendix A does a very nice job in summarizing many of the issues accompanying each of the varying proposed solutions. However, in catching up on the full set of threads for this topic, I have to wonder if we're conflating two highly related set of requirements that should be analyzed separately. Our fundamental problem is that ethernet LAGs, e.g. when using LACP, may blackhole traffic for large periods of time due to convergence issues in that protocol. Similarly, such blackholing may exist when a LAG is statically configured. (Clearly such issues would exist for other forms of LAGs, but our primary discussion has centered around Ethernet. I will largely restrict this response to that problem space.) It is fair to observe that in the case of LAGs managed by LACP that the real problem is it converges too slow. This is something that could be addressed by IEEE. BFD, running as an application on top of Ethernet, could be used to inform an LACP implementation to converge faster. IMO, in such a case, Ethernet encapsulation of BFD makes a lot of sense. BFD provides its functionality by exercising the forwarding path. In the case of a LAG used for IP, the functionality we want to see is that when a link is up, it is forwarding IP traffic. To me, this frames the requirements somewhat differently than the prior discussion although many of the same observations still hold. Where I believe we're conflating the issues is using BFD in one encapsulation, IP or Ethernet, to test the health of the other service. I.e. using IP BFD to inform LACP or Ethernet BFD to inform IP forwarding health. Thus, if we're wanting to verify that IP unicast traffic is correctly being forwarded across a LAG element, BFD should be sent as IP unicast. Among other things, we'll be using the same MAC. If we were instead to be using IP multicast for BFD, the MAC will be different and the fate of the BFD session is less strongly coupled to the ability to properly forward the traffic. This isn't to say that I don't agree nor sympathize with the issues documented in Appendix A of the draft. Multicast does make things *significantly* easier. To take a step back, the problem space I believe we're trying to address in the IETF (rather than in IEEE) is the fact that IP forwarding may fail because elements of a LAG are not being taken down fast enough. I would suggest that a per link BFD solution needs the following properties: - Uses an encapsulation meant to exercise the forwarding path of the traffic it is meant to protect. This is consistent with the original design of BFD. - SHOULD NOT alter the core BFD state machine if at all possible. E.g., MPLS-TP had good reasons to vary it in some circumstances, but was pushed to be compliant when circumstances did not require the deviation. - If the session bootstrapping mechanism deviates from RFC 5880/5881, it MUST NOT cause interoperability issues with BFD sessions on non-LAG links. (I.e. a different UDP destination port.) - SHOULD be port-centric. This means a session should not use a return path that does not exercise the path to be verified for that session. While this is fine for traditional IP BFD, per link BFD with IP encapsulation taking the wrong return path would leave it in question whether it was the forward path or the reverse path that were damaged. - MAY be used as inputs to an aggregated BFD session state between the two systems. As I mentioned above, I'm very sympathetic with the issues that such requirements would place upon an implementor. There are at least two classes of issues here: - We now need a per-link bootstrapping mechanism different from the existing RFC 5880/5881. - BFD done on a traditional host (routing processor/routing engine/etc.) instead of at the line card level becomes messy due to layering issues. (I.e. "here's IP destined for this host, please ignore the routing table".) However, I don't think this problem is terribly much worse than IS-IS or VRRP on such hosts. (I agree that it is still gross.) I'd like us to see a bit more discussion around requirements before completely diving into solutions. However, I think the discussion around the solutions has helped to clarify the issues and the draft has done a good job on driving that discussion. -- Jeff From Alexander.Vainshtein@ecitele.com Sun Jan 8 22:06:22 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514CF21F84F5 for ; Sun, 8 Jan 2012 22:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.384 X-Spam-Level: X-Spam-Status: No, score=-4.384 tagged_above=-999 required=5 tests=[AWL=0.819, 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 M6mv4iukuHZH for ; Sun, 8 Jan 2012 22:06:19 -0800 (PST) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id C669121F845E for ; Sun, 8 Jan 2012 22:06:18 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-16.tower-174.messagelabs.com!1326089174!8124672!3 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 972 invoked from network); 9 Jan 2012 06:06:15 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-16.tower-174.messagelabs.com with SMTP; 9 Jan 2012 06:06:15 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-42-4f0a84ccbf3d Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id A6.FE.08306.CC48A0F4; Mon, 9 Jan 2012 08:10:20 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 9 Jan 2012 08:06:14 +0200 From: Alexander Vainshtein To: Robert Rennison , Pablo Frank Date: Mon, 9 Jan 2012 08:05:50 +0200 Subject: RE: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Topic: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Index: AczOS6wV9RvDVJSxSeyDbmb+yFA09QAR1f66 Message-ID: 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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJsWRmVeSWpSXmKPExsUy+dWnL7pnW7j8Da6uY7SY/vo4m8W+iadY LT7/2cbowOyxc9Zddo8lS34yBTBFNTDaJObl5ZcklqQqpKQWJ9sqBRRlliUmVyopZKbYKhkq KRTkJCan5qbmldgqJRYUpOalKNlxKWAAG6CyzDyF1Lzk/JTMvHRbJc9gf10LC1NLXUMlOzVl Q2NrrpCMzGKFVN3cxMwchdzU4uLE9FQFoEjCFuaMX08Xsxfs1axouriRsYGxS7GLkZNDQsBE 4sPLC8wQtpjEhXvr2boYuTiEBHYzSryacJwZwpnKKHF32n42kCo2AVuJTavvAtkcHCICgRIP 9wqChJkFNCWaTnxmB7FZBFQknnaeZQKxhYHK5555zQJiiwjYSVxY/wHKNpKYvKuVFcTmBRqz rO0qO9yu1tYrYM2cQImPx1vA9jICXff91BomiGXiEreezGeCuFpAYsme81AfiEq8fPyPFaJe VOJO+3pGiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTFoheSYmDK26wTGAUn4VkxSwk7bOQtM9C 0r6AkWUVo2RmTkFJUm66gZFufmmJXmpyZklqTqpecn7uJkZIanmxg/H2Gc1DjAIcjEo8vBLO XP5CrIllxZW5hxglOZiURHmdmoFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgFzIByvCmJlVWp RfkwKQtgUE9kluJOzgemy7ySeGMDAxSOkjhvd/IbXyGBdGDKy05NLUgtgmmV4eBQkuDlBNko WJSanlqRlplTgpBm4uAE2cwDtJkFpIa3uCAxtzgzHSJ/ilFRSpxXASQhAJLIKM2D6wVljfr/ //+/YhQH+lOY918TUBUPMOPAdb8CGswENPjBH3aQwcBcAZeSamDk7lp71587PEZgamH3FL6L m6Vv2r+ydpZKMdCsEDSttNP7oMwg/8lJ/JmQknzXzIZpB9e+UPJek7nBbp/0uz8uVsuWPRF+ lsv0x+HBWlXP2+0iuzn2mryW++/whNWdQ3v9vW1uu3nfd8lLnE5JuVpa+8vzm4Jry+yZVu0v OCZl3J6gnGxx4bMSS3FGoqEWc1FxIgAkLYKP9QMAAA== Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 06:06:22 -0000 Rob, Pablo and all, I concur with Rob: BFD on LAG members using a dedicated Ethertype and used a= s an accelerator for LACP detecting the failures of LAG members looks like t= he right thing to do. Please note also that if micro-BFD sessions are used in conjunction with LAC= P, there is also no need for a new well-known multicast MAC address, you can= use MAC address of the peer port - learned via LACP - as the destination ad= dress (and, of course, the local port MAC address as the source address). As Jeff has indicated in one of his messages on this thread (http://www.ietf= .org/mail-archive/web/rtg-bfd/current/msg01204.html), the operators tend to= use LACP with LAG in any case. As for the exceptions Jeff has mentioned, IM= HO "oldish gear" is not very relevant (it would not support BFD as well). T= his leaves "extremely buggy LACP implementations"... but I do not believe th= at providing workaround for someone's bugs is an important objective. My 2c, Sasha ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Rober= t Rennison [robrennison@gmail.com] Sent: Wednesday, January 04, 2012 10:39 PM To: Pablo Frank Cc: rtg-bfd@ietf.org Subject: Re: Multicast vs Unicast (was BFD on LAG interfaces) Pablo I agree, I am sensing a lot of over-engineering going on in some of the discussions re encapsulations, my gut feel going when I saw the thread start was, it will quickly settle on using a new Ethertype. I lost track of or was never really convinced of what concrete reason folks would want to be using anything other than an L2 encaps, for example the individual links do not have an IP address on them so then there were debates about using IP mcast addresses and demuxing on port , yeuch. So on the K.I.S.S principle my vote goes too for trying to getting a new Ethertype and do not try to get a spec allowing a multiple of encaps as this has the potential to balloon out of all proportion. Cheers Rob Rennison P.s I am also a fan of sticking to having BFD be an adjunct to or an accelerator for LACP so have the micro flow or per interface BFD sessions provide an early indication to LACP that there is a problem with the link. One still potentially needs an overarching slower per LAG group BFD session to keep the upper layers happy if they are expecting BFD on the IP interface. I say potentially because if the interface is now protected by an augmented LACP perhaps the upper layers do not need an explicit BFD, that's a more nuanced discussion. On Wed, Jan 4, 2012 at 11:12 AM, Pablo Frank wrote: > I know there's been some arguments made in favour of option 1 that > suggest that existing ASICs may be better able to handle > IP-encapsulated BFD. Frankly, most vendors are using flexible-enough > parsing hardware so I'm not sure this is a very strong argument > anymore. So I decided to focus on just looking at it from a pure > software IP-stack perspective. > > It seems that either variant of option 1 requires an implementer to do > some pretty ugly hacking to get around existing stack implementations. > I tried getting 1a to work using standard Linux socket APIs and ran > into all sorts of problems. The fundamental issue is that the member > links of a LAG are not normally IP-enabled so trying to bind an IP > multicast group membership didn't work. The other issue was trying to > force the UDP frames out a particular underlying member link was not > possible using the existing socket options for UDP sockets. The only > way I got it to work was using AF_PACKET raw sockets and setting up > some Berkeley Packet Filters to filter out the frames with the correct > L2 multicast MAC address, ethertype, and L3 multicast IP address > (since L2 multicast address is not specific enough). But in this > case, I'm essentially bypassing the IP stack so I don't get to > benefit-from/reuse any of the normal IP stack capabilities (i.e. no IP > header validation, checksum checking, etc.). This was really ugly. I > didn't even try 1b. > > Option 2, on the other hand, was trivially easy using AF_PACKET DGRAM > sockets. It was very straightforward to bind the TBA ethertype, the > TBA multicast MAC, and the interface to use. > > The fact that option 1 was so convoluted isn't surprising given the > obvious layering violations that are taking place here. So unless > there are gigantic barriers in place to prevent us from getting a MAC > address and ethertype assigned for this kind of low-level BFD, I don't > think we should really be seriously considering either variant of > option 1. > > regards, > Pablo > >> 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 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 jeff.tantsura@ericsson.com Sun Jan 8 22:24:53 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE5721F8517 for ; Sun, 8 Jan 2012 22:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, 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 UyYtKF0sZV77 for ; Sun, 8 Jan 2012 22:24:52 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A30A421F847A for ; Sun, 8 Jan 2012 22:24:52 -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 q096Ootl021503; Mon, 9 Jan 2012 00:24:51 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 9 Jan 2012 01:24:45 -0500 From: Jeff Tantsura To: Jeffrey Haas , "rtg-bfd@ietf.org" Date: Mon, 9 Jan 2012 01:24:42 -0500 Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczOl2Cf9TiFZmPqSguNkKkFobZSSw== Message-ID: In-Reply-To: <20120109022815.GN7464@slice> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 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: Mon, 09 Jan 2012 06:24:53 -0000 I completely agree with Jeff's position here, my proposal is again to use unicast IP, it addresses both single and multi session BFD over LAG while requres minimum changes to the existing implementations, keep in mind - any new implementation should still be interoperable with "legacy" BFD over LAG, being RP or LC based, so no changes such as another/new UDP port. BFD is an IP protocol and should not be used on L2 LAG implementations, I have already described in my previous mail how IMHO messaging with internal structures should look like (RIB/etc) --=20 Regards, Jeff On 1/8/12 6:28 PM, "Jeffrey Haas" wrote: >[Speaking currently as an individual contributor.] > >I believe that Appendix A does a very nice job in summarizing many of the >issues accompanying each of the varying proposed solutions. However, in >catching up on the full set of threads for this topic, I have to wonder if >we're conflating two highly related set of requirements that should be >analyzed separately. > >Our fundamental problem is that ethernet LAGs, e.g. when using LACP, may >blackhole traffic for large periods of time due to convergence issues in >that protocol. Similarly, such blackholing may exist when a LAG is >statically configured. > >(Clearly such issues would exist for other forms of LAGs, but our primary >discussion has centered around Ethernet. I will largely restrict this >response to that problem space.) > >It is fair to observe that in the case of LAGs managed by LACP that the >real >problem is it converges too slow. This is something that could be >addressed >by IEEE. BFD, running as an application on top of Ethernet, could be used >to inform an LACP implementation to converge faster. IMO, in such a case, >Ethernet encapsulation of BFD makes a lot of sense. > >BFD provides its functionality by exercising the forwarding path. In the >case of a LAG used for IP, the functionality we want to see is that when a >link is up, it is forwarding IP traffic. To me, this frames the >requirements somewhat differently than the prior discussion although many >of >the same observations still hold. > >Where I believe we're conflating the issues is using BFD in one >encapsulation, IP or Ethernet, to test the health of the other service. >I.e. using IP BFD to inform LACP or Ethernet BFD to inform IP forwarding >health. > >Thus, if we're wanting to verify that IP unicast traffic is correctly >being >forwarded across a LAG element, BFD should be sent as IP unicast. Among >other things, we'll be using the same MAC. If we were instead to be using >IP multicast for BFD, the MAC will be different and the fate of the BFD >session is less strongly coupled to the ability to properly forward the >traffic. > >This isn't to say that I don't agree nor sympathize with the issues >documented in Appendix A of the draft. Multicast does make things >*significantly* easier. > >To take a step back, the problem space I believe we're trying to address >in >the IETF (rather than in IEEE) is the fact that IP forwarding may fail >because elements of a LAG are not being taken down fast enough. > >I would suggest that a per link BFD solution needs the following >properties: >- Uses an encapsulation meant to exercise the forwarding path of the >traffic > it is meant to protect. This is consistent with the original design of > BFD. =20 >- SHOULD NOT alter the core BFD state machine if at all possible. E.g., >MPLS-TP > had good reasons to vary it in some circumstances, but was pushed to be > compliant when circumstances did not require the deviation. >- If the session bootstrapping mechanism deviates from RFC 5880/5881, it > MUST NOT cause interoperability issues with BFD sessions on non-LAG >links. > (I.e. a different UDP destination port.) >- SHOULD be port-centric. This means a session should not use a return >path > that does not exercise the path to be verified for that session. While > this is fine for traditional IP BFD, per link BFD with IP encapsulation > taking the wrong return path would leave it in question whether it was >the > forward path or the reverse path that were damaged. >- MAY be used as inputs to an aggregated BFD session state between the two > systems. > >As I mentioned above, I'm very sympathetic with the issues that such >requirements would place upon an implementor. There are at least two >classes of issues here: >- We now need a per-link bootstrapping mechanism different from the >existing > RFC 5880/5881. =20 >- BFD done on a traditional host (routing processor/routing engine/etc.) > instead of at the line card level becomes messy due to layering issues. > (I.e. "here's IP destined for this host, please ignore the routing > table".) However, I don't think this problem is terribly much worse >than > IS-IS or VRRP on such hosts. (I agree that it is still gross.) > =20 >I'd like us to see a bit more discussion around requirements before >completely diving into solutions. However, I think the discussion around >the solutions has helped to clarify the issues and the draft has done a >good >job on driving that discussion. > >-- Jeff From toms.sanders@gmail.com Mon Jan 9 00:41:08 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4507E21F8525 for ; Mon, 9 Jan 2012 00:41:08 -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 aVzHvajcsGvs for ; Mon, 9 Jan 2012 00:41:07 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C43E321F852C for ; Mon, 9 Jan 2012 00:41:06 -0800 (PST) Received: by werb14 with SMTP id b14so2951919wer.31 for ; Mon, 09 Jan 2012 00:41:06 -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=VGKZ0/TWm+OikIJaijQj/kZJfFXKJOyQmNc+1/moLCU=; b=WVyFaoTNLPczKkrvIUMb/rYZ1zSfwVqp9x0ZlngRnDNB63xewESCbuhoLgAFrhcgPQ f5GCdKBgjCwwFX0O1YuQ+1rVhcoX1KOf0W56Kvea4L2kgrfui4wUBn45ld0PtTcGFS+Z NSUzMu3oltmvqYaD55eH+9Ut+cmsIdMrHADPY= MIME-Version: 1.0 Received: by 10.216.136.232 with SMTP id w82mr6934041wei.46.1326098465918; Mon, 09 Jan 2012 00:41:05 -0800 (PST) Received: by 10.223.120.77 with HTTP; Mon, 9 Jan 2012 00:41:05 -0800 (PST) In-Reply-To: <20120109022815.GN7464@slice> References: <20120109022815.GN7464@slice> Date: Mon, 9 Jan 2012 14:11:05 +0530 Message-ID: Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) From: Tom Sanders To: Jeffrey Haas 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: Mon, 09 Jan 2012 08:41:08 -0000 > > I believe that Appendix A does a very nice job in summarizing many of the > issues accompanying each of the varying proposed solutions. =C2=A0However= , in +1 > > Our fundamental problem is that ethernet LAGs, e.g. when using LACP, may > blackhole traffic for large periods of time due to convergence issues in > that protocol. =C2=A0Similarly, such blackholing may exist when a LAG is > statically configured. > > (Clearly such issues would exist for other forms of LAGs, but our primary > discussion has centered around Ethernet. =C2=A0I will largely restrict th= is > response to that problem space.) > > It is fair to observe that in the case of LAGs managed by LACP that the r= eal > problem is it converges too slow. =C2=A0This is something that could be a= ddressed > by IEEE. =C2=A0BFD, running as an application on top of Ethernet, could b= e used > to inform an LACP implementation to converge faster. =C2=A0IMO, in such a= case, > Ethernet encapsulation of BFD makes a lot of sense. I agree. And btw, isnt this the problem that this draft is attempting to address? > > BFD provides its functionality by exercising the forwarding path. =C2=A0I= n the > case of a LAG used for IP, the functionality we want to see is that when = a > link is up, it is forwarding IP traffic. =C2=A0To me, this frames the Not really. I would not want to restrict ourselves by merely saying "forwarding IP traffic". I dont see why a solution to preclude the possibility of supporting VPLS or VPWS in which case one could have a LAG thats used for forwarding L2 frames. The idea is to get rid of LACP. The idea is to use BFD for fast detection since folks know and understand BFD. We could have achieved the same using ethernet OAM but folks did not want to do that. > requirements somewhat differently than the prior discussion although many= of > the same observations still hold. > > Where I believe we're conflating the issues is using BFD in one > encapsulation, IP or Ethernet, to test the health of the other service. > I.e. using IP BFD to inform LACP or Ethernet BFD to inform IP forwarding > health. > > Thus, if we're wanting to verify that IP unicast traffic is correctly bei= ng AS i mentioned earlier, I think we'll be very myopic if we restrict ourselves to IP unicast traffic. What prevents us from using that link for multicast traffic or L2 traffic? > forwarded across a LAG element, BFD should be sent as IP unicast. =C2=A0A= mong > other things, we'll be using the same MAC. =C2=A0If we were instead to be= using > IP multicast for BFD, the MAC will be different and the fate of the BFD > session is less strongly coupled to the ability to properly forward the > traffic. I think micro BFD sessions are required for required for link liveliness and not IP liveliness. If on operator wants to ensure IP layer liveliness then they must run BFD in the Big Pipe mode (described in Sec 4, bullet "b"). The micro BFD sessions work along with LACP to inform the LAG manager of the current state of the links in the LAG. They are not meant for IP connectivity. Manav and Marc - I hope i am not too much off the mark! BBP (Sec 2.1) uses IP encapsulation which is fine as its this thats meant for IP connectivity verification. > > This isn't to say that I don't agree nor sympathize with the issues > documented in Appendix A of the draft. =C2=A0Multicast does make things > *significantly* easier. Which is why i was earlier rooting for multicast. However, recent discussions on the list have got me thinking and i think i may drifting towards BFD over pure L2 encap mode now. > > To take a step back, the problem space I believe we're trying to address = in > the IETF (rather than in IEEE) is the fact that IP forwarding may fail > because elements of a LAG are not being taken down fast enough. No. I think this is the disconnect. Its meant to detect fast link failures. > > I would suggest that a per link BFD solution needs the following properti= es: > - Uses an encapsulation meant to exercise the forwarding path of the traf= fic > =C2=A0it is meant to protect. =C2=A0This is consistent with the original = design of > =C2=A0BFD. > - SHOULD NOT alter the core BFD state machine if at all possible. =C2=A0E= .g., MPLS-TP > =C2=A0had good reasons to vary it in some circumstances, but was pushed t= o be > =C2=A0compliant when circumstances did not require the deviation. > - If the session bootstrapping mechanism deviates from RFC 5880/5881, it > =C2=A0MUST NOT cause interoperability issues with BFD sessions on non-LAG= links. > =C2=A0(I.e. a different UDP destination port.) This means that you assume that BFD only works in mode described in Sec 4, bullet "a". I am not sure if this was discussed. > - We now need a per-link bootstrapping mechanism different from the exist= ing > =C2=A0RFC 5880/5881. > - BFD done on a traditional host (routing processor/routing engine/etc.) > =C2=A0instead of at the line card level becomes messy due to layering iss= ues. > =C2=A0(I.e. "here's IP destined for this host, please ignore the routing > =C2=A0table".) =C2=A0However, I don't think this problem is terribly much= worse than > =C2=A0IS-IS or VRRP on such hosts. =C2=A0(I agree that it is still gross.= ) IS-IS uses a well known L2 address so its really not a violation. > > I'd like us to see a bit more discussion around requirements before > completely diving into solutions. =C2=A0However, I think the discussion a= round > the solutions has helped to clarify the issues and the draft has done a g= ood > job on driving that discussion. Yes, i agree. We all appreciate the work done by the authors of draft-mmm-bfd-on-lags and its definitely helped clear the fog surrounding the problem and the solution space. I would urge the folks to first discuss whether its to be L2 or L3, before getting into the specifics of whether it should be Unicast or Multicast. -- Toms From Alexander.Vainshtein@ecitele.com Mon Jan 9 01:18:37 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1173021F8536 for ; Mon, 9 Jan 2012 01:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.15 X-Spam-Level: X-Spam-Status: No, score=-5.15 tagged_above=-999 required=5 tests=[AWL=1.449, 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 CUMZGJcQchVf for ; Mon, 9 Jan 2012 01:18:35 -0800 (PST) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id D207C21F86B5 for ; Mon, 9 Jan 2012 01:18:34 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-5.tower-174.messagelabs.com!1326100702!8327518!9 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 21645 invoked from network); 9 Jan 2012 09:18:29 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-5.tower-174.messagelabs.com with SMTP; 9 Jan 2012 09:18:29 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-10-4f0ab1daf489 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 5E.A3.08306.AD1BA0F4; Mon, 9 Jan 2012 11:22:34 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 9 Jan 2012 11:18:28 +0200 From: Alexander Vainshtein To: Tom Sanders Date: Mon, 9 Jan 2012 11:18:27 +0200 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczOqmvGiSXxAYgVQF+4co04nqGPmQABJjPg Message-ID: References: <20120109022815.GN7464@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTW0wTQRR1utt2W1iyVLBD40ddDIpJFVCTGiiaELV+EPD1448u7dhubLe1 uxjrCzQRA2qDwSg2AY3hQxCtL4gajdAYtT5JDFFBjChGRU2k+ICI4CyriHG+zsw5556Zyb0U YRjQmChekFBA4DysRk/W9Me/WLrO64uyhgbyrDfaP6mtgyOtwNoZb1QtIexXwj1ae0PDsMr+ +GCLuphYVw7yOEHwSZyEzE4kOmxscYDfwjmCrJl32ths1uz3cA7kRYJkYzm/HwlONl9v/m/l YRkvmJHg8Dl5wWVjV6wuslitCxdZstn8jPTs+bn6NW5eNCOLl+M9Zi8SRc6FzPhkwyXCfSc2 y79n+daG9xc15aB2aRXQUZBZAJt+xLUKngY7XkQ0VUBPGZgrAL4cug6UTQ2ANc1v1bJKw9jg hdM9GhmnMLPhmc9VKhkTjB1W3LxHyJhkZsIjvaFx/VSGg6Gzt7WKvgQO9dWTCs6BhyrrxzU0 sxIe7KwllbBRAI91xMeL6jBR2dE6XhTg632/2/w7zAi7+o6rlGszsOHaI0LBqfD961G1ok+F z/dF8AsorM+EkavzFOsMeHh/r1bJTYaxY32kYk2D7aeektXAGJ6UEP7rDk9yhye5TwCyCaTx Hr9U4nVl5Vh8pdJc5OAl5EFzHT7vBaA0zLvLoPt+ZhQwFGATaVigLzKouS1i0BsFaZSKTaVj EXyUVOJzBt2c6F4fKPUgMQogRbApdDCEOdrJBbehgO8PZcUffYgwJTh8uDUFaf38rKx/NqyR 3u/4WGhgXLjvNiHkR4E/1ukUxUJafw5XTQ4gF9q6kfdIf2kVpZOTE3FysqyhRT/nFXmXwt8F FurJ7rqHwEAKPgGZjLRRFjGyyF0qTNSRJ6VsbGysHxjxm6fSU2RVIp6jiUr9OESFQ16OaOUQ PB8TlKkcVBwYHihsbGkudIVqvaFl56IdmZv3VJdua2NWvR0Vh052pY8W5EbaO7frBhMDt3Rp U+AH5ubiFJhzZO+rjOq2VusSd/xoy52d194UG+D2uvpv3aoX7GC3dkeGO2mXxjn801QXe6aL rj3d9mVvbF8jKqhQC7vtD3rvfS1M8PSUiSwpurnsOURA5H4Bh1/iXQQEAAA= Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:18:37 -0000 VG9tLCBhbmQgYWxsLA0KDQpJIHN0cm9uZ2x5IGRpc2FncmVlIHdpdGggdGhlIGZvbGxvd2lu ZyBzdGF0ZW1lbnQgaW4geW91ciBtZXNzYWdlOiAgIlRoZSBpZGVhIGlzIHRvIGdldCByaWQg b2YgTEFDUCAiLg0KDQpSZWdhcmRzLA0KICAgICBTYXNoYQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIFRvbSBTYW5kZXJz DQo+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAwOSwgMjAxMiAxMDo0MSBBTQ0KPiBUbzogSmVm ZnJleSBIYWFzDQo+IENjOiBydGctYmZkQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBCRkQg b24gTEFHIHJlcXVpcmVtZW50cyAod2FzIFJlOiBNdWx0aWNhc3QgdnMgVW5pY2FzdCAod2Fz DQo+IEJGRCBvbiBMQUcgaW50ZXJmYWNlcykpDQo+IA0KPiA+DQo+ID4gSSBiZWxpZXZlIHRo YXQgQXBwZW5kaXggQSBkb2VzIGEgdmVyeSBuaWNlIGpvYiBpbiBzdW1tYXJpemluZyBtYW55 IG9mIHRoZQ0KPiA+IGlzc3VlcyBhY2NvbXBhbnlpbmcgZWFjaCBvZiB0aGUgdmFyeWluZyBw cm9wb3NlZCBzb2x1dGlvbnMuIMKgSG93ZXZlciwgaW4NCj4gDQo+ICsxDQo+IA0KPiA+DQo+ ID4gT3VyIGZ1bmRhbWVudGFsIHByb2JsZW0gaXMgdGhhdCBldGhlcm5ldCBMQUdzLCBlLmcu IHdoZW4gdXNpbmcgTEFDUCwNCj4gbWF5DQo+ID4gYmxhY2tob2xlIHRyYWZmaWMgZm9yIGxh cmdlIHBlcmlvZHMgb2YgdGltZSBkdWUgdG8gY29udmVyZ2VuY2UgaXNzdWVzIGluDQo+ID4g dGhhdCBwcm90b2NvbC4gwqBTaW1pbGFybHksIHN1Y2ggYmxhY2tob2xpbmcgbWF5IGV4aXN0 IHdoZW4gYSBMQUcgaXMNCj4gPiBzdGF0aWNhbGx5IGNvbmZpZ3VyZWQuDQo+ID4NCj4gPiAo Q2xlYXJseSBzdWNoIGlzc3VlcyB3b3VsZCBleGlzdCBmb3Igb3RoZXIgZm9ybXMgb2YgTEFH cywgYnV0IG91ciBwcmltYXJ5DQo+ID4gZGlzY3Vzc2lvbiBoYXMgY2VudGVyZWQgYXJvdW5k IEV0aGVybmV0LiDCoEkgd2lsbCBsYXJnZWx5IHJlc3RyaWN0IHRoaXMNCj4gPiByZXNwb25z ZSB0byB0aGF0IHByb2JsZW0gc3BhY2UuKQ0KPiA+DQo+ID4gSXQgaXMgZmFpciB0byBvYnNl cnZlIHRoYXQgaW4gdGhlIGNhc2Ugb2YgTEFHcyBtYW5hZ2VkIGJ5IExBQ1AgdGhhdCB0aGUg cmVhbA0KPiA+IHByb2JsZW0gaXMgaXQgY29udmVyZ2VzIHRvbyBzbG93LiDCoFRoaXMgaXMg c29tZXRoaW5nIHRoYXQgY291bGQgYmUNCj4gYWRkcmVzc2VkDQo+ID4gYnkgSUVFRS4gwqBC RkQsIHJ1bm5pbmcgYXMgYW4gYXBwbGljYXRpb24gb24gdG9wIG9mIEV0aGVybmV0LCBjb3Vs ZCBiZSB1c2VkDQo+ID4gdG8gaW5mb3JtIGFuIExBQ1AgaW1wbGVtZW50YXRpb24gdG8gY29u dmVyZ2UgZmFzdGVyLiDCoElNTywgaW4gc3VjaCBhIGNhc2UsDQo+ID4gRXRoZXJuZXQgZW5j YXBzdWxhdGlvbiBvZiBCRkQgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UuDQo+IA0KPiBJIGFncmVl Lg0KPiANCj4gQW5kIGJ0dywgaXNudCB0aGlzIHRoZSBwcm9ibGVtIHRoYXQgdGhpcyBkcmFm dCBpcyBhdHRlbXB0aW5nIHRvIGFkZHJlc3M/DQo+IA0KPiA+DQo+ID4gQkZEIHByb3ZpZGVz IGl0cyBmdW5jdGlvbmFsaXR5IGJ5IGV4ZXJjaXNpbmcgdGhlIGZvcndhcmRpbmcgcGF0aC4g wqBJbiB0aGUNCj4gPiBjYXNlIG9mIGEgTEFHIHVzZWQgZm9yIElQLCB0aGUgZnVuY3Rpb25h bGl0eSB3ZSB3YW50IHRvIHNlZSBpcyB0aGF0IHdoZW4gYQ0KPiA+IGxpbmsgaXMgdXAsIGl0 IGlzIGZvcndhcmRpbmcgSVAgdHJhZmZpYy4gwqBUbyBtZSwgdGhpcyBmcmFtZXMgdGhlDQo+ IA0KPiBOb3QgcmVhbGx5Lg0KPiANCj4gSSB3b3VsZCBub3Qgd2FudCB0byByZXN0cmljdCBv dXJzZWx2ZXMgYnkgbWVyZWx5IHNheWluZyAiZm9yd2FyZGluZyBJUA0KPiB0cmFmZmljIi4g SSBkb250IHNlZSB3aHkgYSBzb2x1dGlvbiB0byBwcmVjbHVkZSB0aGUgcG9zc2liaWxpdHkg b2YNCj4gc3VwcG9ydGluZyBWUExTIG9yIFZQV1MgaW4gd2hpY2ggY2FzZSBvbmUgY291bGQg aGF2ZSBhIExBRyB0aGF0cyB1c2VkDQo+IGZvciBmb3J3YXJkaW5nIEwyIGZyYW1lcy4NCj4g DQo+IFRoZSBpZGVhIGlzIHRvIGdldCByaWQgb2YgTEFDUC4gVGhlIGlkZWEgaXMgdG8gdXNl IEJGRCBmb3IgZmFzdA0KPiBkZXRlY3Rpb24gc2luY2UgZm9sa3Mga25vdyBhbmQgdW5kZXJz dGFuZCBCRkQuIFdlIGNvdWxkIGhhdmUgYWNoaWV2ZWQNCj4gdGhlIHNhbWUgdXNpbmcgZXRo ZXJuZXQgT0FNIGJ1dCBmb2xrcyBkaWQgbm90IHdhbnQgdG8gZG8gdGhhdC4NCj4gDQo+ID4g cmVxdWlyZW1lbnRzIHNvbWV3aGF0IGRpZmZlcmVudGx5IHRoYW4gdGhlIHByaW9yIGRpc2N1 c3Npb24gYWx0aG91Z2gNCj4gbWFueSBvZg0KPiA+IHRoZSBzYW1lIG9ic2VydmF0aW9ucyBz dGlsbCBob2xkLg0KPiA+DQo+ID4gV2hlcmUgSSBiZWxpZXZlIHdlJ3JlIGNvbmZsYXRpbmcg dGhlIGlzc3VlcyBpcyB1c2luZyBCRkQgaW4gb25lDQo+ID4gZW5jYXBzdWxhdGlvbiwgSVAg b3IgRXRoZXJuZXQsIHRvIHRlc3QgdGhlIGhlYWx0aCBvZiB0aGUgb3RoZXIgc2VydmljZS4N Cj4gPiBJLmUuIHVzaW5nIElQIEJGRCB0byBpbmZvcm0gTEFDUCBvciBFdGhlcm5ldCBCRkQg dG8gaW5mb3JtIElQIGZvcndhcmRpbmcNCj4gPiBoZWFsdGguDQo+ID4NCj4gPiBUaHVzLCBp ZiB3ZSdyZSB3YW50aW5nIHRvIHZlcmlmeSB0aGF0IElQIHVuaWNhc3QgdHJhZmZpYyBpcyBj b3JyZWN0bHkgYmVpbmcNCj4gDQo+IEFTIGkgbWVudGlvbmVkIGVhcmxpZXIsIEkgdGhpbmsg d2UnbGwgYmUgdmVyeSBteW9waWMgaWYgd2UgcmVzdHJpY3QNCj4gb3Vyc2VsdmVzIHRvIElQ IHVuaWNhc3QgdHJhZmZpYy4gV2hhdCBwcmV2ZW50cyB1cyBmcm9tIHVzaW5nIHRoYXQgbGlu aw0KPiBmb3IgbXVsdGljYXN0IHRyYWZmaWMgb3IgTDIgdHJhZmZpYz8NCj4gDQo+ID4gZm9y d2FyZGVkIGFjcm9zcyBhIExBRyBlbGVtZW50LCBCRkQgc2hvdWxkIGJlIHNlbnQgYXMgSVAg dW5pY2FzdC4gwqBBbW9uZw0KPiA+IG90aGVyIHRoaW5ncywgd2UnbGwgYmUgdXNpbmcgdGhl IHNhbWUgTUFDLiDCoElmIHdlIHdlcmUgaW5zdGVhZCB0byBiZSB1c2luZw0KPiA+IElQIG11 bHRpY2FzdCBmb3IgQkZELCB0aGUgTUFDIHdpbGwgYmUgZGlmZmVyZW50IGFuZCB0aGUgZmF0 ZSBvZiB0aGUgQkZEDQo+ID4gc2Vzc2lvbiBpcyBsZXNzIHN0cm9uZ2x5IGNvdXBsZWQgdG8g dGhlIGFiaWxpdHkgdG8gcHJvcGVybHkgZm9yd2FyZCB0aGUNCj4gPiB0cmFmZmljLg0KPiAN Cj4gSSB0aGluayBtaWNybyBCRkQgc2Vzc2lvbnMgYXJlIHJlcXVpcmVkIGZvciByZXF1aXJl ZCBmb3IgbGluaw0KPiBsaXZlbGluZXNzIGFuZCBub3QgSVAgbGl2ZWxpbmVzcy4gSWYgb24g b3BlcmF0b3Igd2FudHMgdG8gZW5zdXJlIElQDQo+IGxheWVyIGxpdmVsaW5lc3MgdGhlbiB0 aGV5IG11c3QgcnVuIEJGRCBpbiB0aGUgQmlnIFBpcGUgbW9kZQ0KPiAoZGVzY3JpYmVkIGlu IFNlYyA0LCBidWxsZXQgImIiKS4gVGhlIG1pY3JvIEJGRCBzZXNzaW9ucyB3b3JrIGFsb25n DQo+IHdpdGggTEFDUCB0byBpbmZvcm0gdGhlIExBRyBtYW5hZ2VyIG9mIHRoZSBjdXJyZW50 IHN0YXRlIG9mIHRoZSBsaW5rcw0KPiBpbiB0aGUgTEFHLiBUaGV5IGFyZSBub3QgbWVhbnQg Zm9yIElQIGNvbm5lY3Rpdml0eS4gTWFuYXYgYW5kIE1hcmMgLSBJDQo+IGhvcGUgaSBhbSBu b3QgdG9vIG11Y2ggb2ZmIHRoZSBtYXJrIQ0KPiANCj4gQkJQIChTZWMgMi4xKSB1c2VzIElQ IGVuY2Fwc3VsYXRpb24gd2hpY2ggaXMgZmluZSBhcyBpdHMgdGhpcyB0aGF0cw0KPiBtZWFu dCBmb3IgSVAgY29ubmVjdGl2aXR5IHZlcmlmaWNhdGlvbi4NCj4gDQo+ID4NCj4gPiBUaGlz IGlzbid0IHRvIHNheSB0aGF0IEkgZG9uJ3QgYWdyZWUgbm9yIHN5bXBhdGhpemUgd2l0aCB0 aGUgaXNzdWVzDQo+ID4gZG9jdW1lbnRlZCBpbiBBcHBlbmRpeCBBIG9mIHRoZSBkcmFmdC4g wqBNdWx0aWNhc3QgZG9lcyBtYWtlIHRoaW5ncw0KPiA+ICpzaWduaWZpY2FudGx5KiBlYXNp ZXIuDQo+IA0KPiBXaGljaCBpcyB3aHkgaSB3YXMgZWFybGllciByb290aW5nIGZvciBtdWx0 aWNhc3QuIEhvd2V2ZXIsIHJlY2VudA0KPiBkaXNjdXNzaW9ucyBvbiB0aGUgbGlzdCBoYXZl IGdvdCBtZSB0aGlua2luZyBhbmQgaSB0aGluayBpIG1heQ0KPiBkcmlmdGluZyB0b3dhcmRz IEJGRCBvdmVyIHB1cmUgTDIgZW5jYXAgbW9kZSBub3cuDQo+IA0KPiA+DQo+ID4gVG8gdGFr ZSBhIHN0ZXAgYmFjaywgdGhlIHByb2JsZW0gc3BhY2UgSSBiZWxpZXZlIHdlJ3JlIHRyeWlu ZyB0byBhZGRyZXNzIGluDQo+ID4gdGhlIElFVEYgKHJhdGhlciB0aGFuIGluIElFRUUpIGlz IHRoZSBmYWN0IHRoYXQgSVAgZm9yd2FyZGluZyBtYXkgZmFpbA0KPiA+IGJlY2F1c2UgZWxl bWVudHMgb2YgYSBMQUcgYXJlIG5vdCBiZWluZyB0YWtlbiBkb3duIGZhc3QgZW5vdWdoLg0K PiANCj4gTm8uIEkgdGhpbmsgdGhpcyBpcyB0aGUgZGlzY29ubmVjdC4gSXRzIG1lYW50IHRv IGRldGVjdCBmYXN0IGxpbmsgZmFpbHVyZXMuDQo+IA0KPiA+DQo+ID4gSSB3b3VsZCBzdWdn ZXN0IHRoYXQgYSBwZXIgbGluayBCRkQgc29sdXRpb24gbmVlZHMgdGhlIGZvbGxvd2luZw0K PiBwcm9wZXJ0aWVzOg0KPiA+IC0gVXNlcyBhbiBlbmNhcHN1bGF0aW9uIG1lYW50IHRvIGV4 ZXJjaXNlIHRoZSBmb3J3YXJkaW5nIHBhdGggb2YgdGhlDQo+IHRyYWZmaWMNCj4gPiDCoGl0 IGlzIG1lYW50IHRvIHByb3RlY3QuIMKgVGhpcyBpcyBjb25zaXN0ZW50IHdpdGggdGhlIG9y aWdpbmFsIGRlc2lnbiBvZg0KPiA+IMKgQkZELg0KPiA+IC0gU0hPVUxEIE5PVCBhbHRlciB0 aGUgY29yZSBCRkQgc3RhdGUgbWFjaGluZSBpZiBhdCBhbGwgcG9zc2libGUuIMKgRS5nLiwN Cj4gTVBMUy1UUA0KPiA+IMKgaGFkIGdvb2QgcmVhc29ucyB0byB2YXJ5IGl0IGluIHNvbWUg Y2lyY3Vtc3RhbmNlcywgYnV0IHdhcyBwdXNoZWQgdG8gYmUNCj4gPiDCoGNvbXBsaWFudCB3 aGVuIGNpcmN1bXN0YW5jZXMgZGlkIG5vdCByZXF1aXJlIHRoZSBkZXZpYXRpb24uDQo+ID4g LSBJZiB0aGUgc2Vzc2lvbiBib290c3RyYXBwaW5nIG1lY2hhbmlzbSBkZXZpYXRlcyBmcm9t IFJGQyA1ODgwLzU4ODEsIGl0DQo+ID4gwqBNVVNUIE5PVCBjYXVzZSBpbnRlcm9wZXJhYmls aXR5IGlzc3VlcyB3aXRoIEJGRCBzZXNzaW9ucyBvbiBub24tTEFHDQo+IGxpbmtzLg0KPiA+ IMKgKEkuZS4gYSBkaWZmZXJlbnQgVURQIGRlc3RpbmF0aW9uIHBvcnQuKQ0KPiANCj4gVGhp cyBtZWFucyB0aGF0IHlvdSBhc3N1bWUgdGhhdCBCRkQgb25seSB3b3JrcyBpbiBtb2RlIGRl c2NyaWJlZCBpbg0KPiBTZWMgNCwgYnVsbGV0ICJhIi4NCj4gDQo+IEkgYW0gbm90IHN1cmUg aWYgdGhpcyB3YXMgZGlzY3Vzc2VkLg0KPiANCj4gPiAtIFdlIG5vdyBuZWVkIGEgcGVyLWxp bmsgYm9vdHN0cmFwcGluZyBtZWNoYW5pc20gZGlmZmVyZW50IGZyb20gdGhlDQo+IGV4aXN0 aW5nDQo+ID4gwqBSRkMgNTg4MC81ODgxLg0KPiA+IC0gQkZEIGRvbmUgb24gYSB0cmFkaXRp b25hbCBob3N0IChyb3V0aW5nIHByb2Nlc3Nvci9yb3V0aW5nIGVuZ2luZS9ldGMuKQ0KPiA+ IMKgaW5zdGVhZCBvZiBhdCB0aGUgbGluZSBjYXJkIGxldmVsIGJlY29tZXMgbWVzc3kgZHVl IHRvIGxheWVyaW5nIGlzc3Vlcy4NCj4gPiDCoChJLmUuICJoZXJlJ3MgSVAgZGVzdGluZWQg Zm9yIHRoaXMgaG9zdCwgcGxlYXNlIGlnbm9yZSB0aGUgcm91dGluZw0KPiA+IMKgdGFibGUi LikgwqBIb3dldmVyLCBJIGRvbid0IHRoaW5rIHRoaXMgcHJvYmxlbSBpcyB0ZXJyaWJseSBt dWNoIHdvcnNlIHRoYW4NCj4gPiDCoElTLUlTIG9yIFZSUlAgb24gc3VjaCBob3N0cy4gwqAo SSBhZ3JlZSB0aGF0IGl0IGlzIHN0aWxsIGdyb3NzLikNCj4gDQo+IElTLUlTIHVzZXMgYSB3 ZWxsIGtub3duIEwyIGFkZHJlc3Mgc28gaXRzIHJlYWxseSBub3QgYSB2aW9sYXRpb24uDQo+ IA0KPiA+DQo+ID4gSSdkIGxpa2UgdXMgdG8gc2VlIGEgYml0IG1vcmUgZGlzY3Vzc2lvbiBh cm91bmQgcmVxdWlyZW1lbnRzIGJlZm9yZQ0KPiA+IGNvbXBsZXRlbHkgZGl2aW5nIGludG8g c29sdXRpb25zLiDCoEhvd2V2ZXIsIEkgdGhpbmsgdGhlIGRpc2N1c3Npb24gYXJvdW5kDQo+ ID4gdGhlIHNvbHV0aW9ucyBoYXMgaGVscGVkIHRvIGNsYXJpZnkgdGhlIGlzc3VlcyBhbmQg dGhlIGRyYWZ0IGhhcyBkb25lIGEgZ29vZA0KPiA+IGpvYiBvbiBkcml2aW5nIHRoYXQgZGlz Y3Vzc2lvbi4NCj4gDQo+IFllcywgaSBhZ3JlZS4gV2UgYWxsIGFwcHJlY2lhdGUgdGhlIHdv cmsgZG9uZSBieSB0aGUgYXV0aG9ycyBvZg0KPiBkcmFmdC1tbW0tYmZkLW9uLWxhZ3MgYW5k IGl0cyBkZWZpbml0ZWx5IGhlbHBlZCBjbGVhciB0aGUgZm9nDQo+IHN1cnJvdW5kaW5nIHRo ZSBwcm9ibGVtIGFuZCB0aGUgc29sdXRpb24gc3BhY2UuDQo+IA0KPiBJIHdvdWxkIHVyZ2Ug dGhlIGZvbGtzIHRvIGZpcnN0IGRpc2N1c3Mgd2hldGhlciBpdHMgdG8gYmUgTDIgb3IgTDMs DQo+IGJlZm9yZSBnZXR0aW5nIGludG8gdGhlIHNwZWNpZmljcyBvZiB3aGV0aGVyIGl0IHNo b3VsZCBiZSBVbmljYXN0IG9yDQo+IE11bHRpY2FzdC4NCj4gDQo+IC0tDQo+IFRvbXMNCg0K DQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9u bHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQg d2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBi eSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBh bmQgYWxsIGNvcGllcyB0aGVyZW9mLg0KDQo= From mach.chen@huawei.com Mon Jan 9 01:41:44 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8321F8673 for ; Mon, 9 Jan 2012 01:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 XRnbk3u29EAo for ; Mon, 9 Jan 2012 01:41:43 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C663B21F866E for ; Mon, 9 Jan 2012 01:41:42 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXI00JPWYV5KH@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 09 Jan 2012 17:40:17 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXI00AXYYV5AV@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Mon, 09 Jan 2012 17:40:17 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGF05933; Mon, 09 Jan 2012 17:40:16 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 09 Jan 2012 17:40:14 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.67]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Mon, 09 Jan 2012 17:40:09 +0800 Date: Mon, 09 Jan 2012 09:40:08 +0000 From: Mach Chen Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) In-reply-to: X-Originating-IP: [10.108.4.53] To: Tom Sanders , Jeffrey Haas Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-index: AQHMznaGCCAoqs2rT0KAyRf+IaOnCZYDMdCAgACMtyA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120109022815.GN7464@slice> Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:41:44 -0000 SGkgVG9tLA0KDQpHb29kIHBvaW50IQ0KDQpPbmUgY2xhcmlmaWNhdGlvbiBhYm91dCB0aGUgc3Rh dGU6DQo+IFRoZSBpZGVhIGlzIHRvIGdldCByaWQgb2YgTEFDUC4uLg0KDQpUaGUgZHJhZnQgZG9l cyBub3QgaW50ZW5kIHRvIHJlcGxhY2UgTEFDUCwgaXQncyBhbiBhY2NlbGVyYXRvciBmb3IgZmFp bHVyZXMgZGV0ZWN0aW9uLCBtaWNyby1CRkQgc2Vzc2lvbnMgY291bGQgYmUgcnVubmluZyBlaXRo ZXIgd2l0aCBvciB3aXRob3V0IExBQ1AuDQoNCkkgdGhpbmsgdGhlIHJlcXVpcmVtZW50KGZhc3Qg ZmFpbHVyZXMgZGV0ZWN0aW9uIGZvciBtZW1iZXIgbGlua3Mgb2YgYSBMQUcpIGlzIG9idmlvdXMs IGFuZCBvdXIgZHJhZnQgaGFzIGxpc3RlZCBtb3N0IG9mIHRoZSBjYW5kaWRhdGUgc29sdXRpb25z LCBleGlzdGluZyBkaXNjdXNzaW9ucyBtYWlubHkgZm9jdXMgb24gd2hpY2ggc29sdXRpb24gaXMg dGhlIHJpZ2h0IG9uZSBhbmQgd2UgaG9wZSBmaW5hbGx5IHRoZSBXRyBjYW4gY29udmVyZ2Ugb24g b25seSBvbmUgc29sdXRpb24uIA0KDQpCZXN0IHJlZ2FyZHMsDQpNYWNoDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFRvbSBTYW5kZXJzDQo+ IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAwOSwgMjAxMiA0OjQxIFBNDQo+IFRvOiBKZWZmcmV5IEhh YXMNCj4gQ2M6IHJ0Zy1iZmRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEJGRCBvbiBMQUcgcmVx dWlyZW1lbnRzICh3YXMgUmU6IE11bHRpY2FzdCB2cyBVbmljYXN0ICh3YXMgQkZEDQo+IG9uIExB RyBpbnRlcmZhY2VzKSkNCj4gDQo+ID4NCj4gPiBJIGJlbGlldmUgdGhhdCBBcHBlbmRpeCBBIGRv ZXMgYSB2ZXJ5IG5pY2Ugam9iIGluIHN1bW1hcml6aW5nIG1hbnkgb2YgdGhlDQo+ID4gaXNzdWVz IGFjY29tcGFueWluZyBlYWNoIG9mIHRoZSB2YXJ5aW5nIHByb3Bvc2VkIHNvbHV0aW9ucy4gwqBI b3dldmVyLCBpbg0KPiANCj4gKzENCj4gDQo+ID4NCj4gPiBPdXIgZnVuZGFtZW50YWwgcHJvYmxl bSBpcyB0aGF0IGV0aGVybmV0IExBR3MsIGUuZy4gd2hlbiB1c2luZyBMQUNQLCBtYXkNCj4gPiBi bGFja2hvbGUgdHJhZmZpYyBmb3IgbGFyZ2UgcGVyaW9kcyBvZiB0aW1lIGR1ZSB0byBjb252ZXJn ZW5jZSBpc3N1ZXMgaW4NCj4gPiB0aGF0IHByb3RvY29sLiDCoFNpbWlsYXJseSwgc3VjaCBibGFj a2hvbGluZyBtYXkgZXhpc3Qgd2hlbiBhIExBRyBpcw0KPiA+IHN0YXRpY2FsbHkgY29uZmlndXJl ZC4NCj4gPg0KPiA+IChDbGVhcmx5IHN1Y2ggaXNzdWVzIHdvdWxkIGV4aXN0IGZvciBvdGhlciBm b3JtcyBvZiBMQUdzLCBidXQgb3VyIHByaW1hcnkNCj4gPiBkaXNjdXNzaW9uIGhhcyBjZW50ZXJl ZCBhcm91bmQgRXRoZXJuZXQuIMKgSSB3aWxsIGxhcmdlbHkgcmVzdHJpY3QgdGhpcw0KPiA+IHJl c3BvbnNlIHRvIHRoYXQgcHJvYmxlbSBzcGFjZS4pDQo+ID4NCj4gPiBJdCBpcyBmYWlyIHRvIG9i c2VydmUgdGhhdCBpbiB0aGUgY2FzZSBvZiBMQUdzIG1hbmFnZWQgYnkgTEFDUCB0aGF0IHRoZSBy ZWFsDQo+ID4gcHJvYmxlbSBpcyBpdCBjb252ZXJnZXMgdG9vIHNsb3cuIMKgVGhpcyBpcyBzb21l dGhpbmcgdGhhdCBjb3VsZCBiZSBhZGRyZXNzZWQNCj4gPiBieSBJRUVFLiDCoEJGRCwgcnVubmlu ZyBhcyBhbiBhcHBsaWNhdGlvbiBvbiB0b3Agb2YgRXRoZXJuZXQsIGNvdWxkIGJlIHVzZWQNCj4g PiB0byBpbmZvcm0gYW4gTEFDUCBpbXBsZW1lbnRhdGlvbiB0byBjb252ZXJnZSBmYXN0ZXIuIMKg SU1PLCBpbiBzdWNoIGEgY2FzZSwNCj4gPiBFdGhlcm5ldCBlbmNhcHN1bGF0aW9uIG9mIEJGRCBt YWtlcyBhIGxvdCBvZiBzZW5zZS4NCj4gDQo+IEkgYWdyZWUuDQo+IA0KPiBBbmQgYnR3LCBpc250 IHRoaXMgdGhlIHByb2JsZW0gdGhhdCB0aGlzIGRyYWZ0IGlzIGF0dGVtcHRpbmcgdG8gYWRkcmVz cz8NCj4gDQo+ID4NCj4gPiBCRkQgcHJvdmlkZXMgaXRzIGZ1bmN0aW9uYWxpdHkgYnkgZXhlcmNp c2luZyB0aGUgZm9yd2FyZGluZyBwYXRoLiDCoEluIHRoZQ0KPiA+IGNhc2Ugb2YgYSBMQUcgdXNl ZCBmb3IgSVAsIHRoZSBmdW5jdGlvbmFsaXR5IHdlIHdhbnQgdG8gc2VlIGlzIHRoYXQgd2hlbiBh DQo+ID4gbGluayBpcyB1cCwgaXQgaXMgZm9yd2FyZGluZyBJUCB0cmFmZmljLiDCoFRvIG1lLCB0 aGlzIGZyYW1lcyB0aGUNCj4gDQo+IE5vdCByZWFsbHkuDQo+IA0KPiBJIHdvdWxkIG5vdCB3YW50 IHRvIHJlc3RyaWN0IG91cnNlbHZlcyBieSBtZXJlbHkgc2F5aW5nICJmb3J3YXJkaW5nIElQDQo+ IHRyYWZmaWMiLiBJIGRvbnQgc2VlIHdoeSBhIHNvbHV0aW9uIHRvIHByZWNsdWRlIHRoZSBwb3Nz aWJpbGl0eSBvZg0KPiBzdXBwb3J0aW5nIFZQTFMgb3IgVlBXUyBpbiB3aGljaCBjYXNlIG9uZSBj b3VsZCBoYXZlIGEgTEFHIHRoYXRzIHVzZWQNCj4gZm9yIGZvcndhcmRpbmcgTDIgZnJhbWVzLg0K PiANCj4gVGhlIGlkZWEgaXMgdG8gZ2V0IHJpZCBvZiBMQUNQLiBUaGUgaWRlYSBpcyB0byB1c2Ug QkZEIGZvciBmYXN0DQo+IGRldGVjdGlvbiBzaW5jZSBmb2xrcyBrbm93IGFuZCB1bmRlcnN0YW5k IEJGRC4gV2UgY291bGQgaGF2ZSBhY2hpZXZlZA0KPiB0aGUgc2FtZSB1c2luZyBldGhlcm5ldCBP QU0gYnV0IGZvbGtzIGRpZCBub3Qgd2FudCB0byBkbyB0aGF0Lg0KPiANCj4gPiByZXF1aXJlbWVu dHMgc29tZXdoYXQgZGlmZmVyZW50bHkgdGhhbiB0aGUgcHJpb3IgZGlzY3Vzc2lvbiBhbHRob3Vn aCBtYW55DQo+IG9mDQo+ID4gdGhlIHNhbWUgb2JzZXJ2YXRpb25zIHN0aWxsIGhvbGQuDQo+ID4N Cj4gPiBXaGVyZSBJIGJlbGlldmUgd2UncmUgY29uZmxhdGluZyB0aGUgaXNzdWVzIGlzIHVzaW5n IEJGRCBpbiBvbmUNCj4gPiBlbmNhcHN1bGF0aW9uLCBJUCBvciBFdGhlcm5ldCwgdG8gdGVzdCB0 aGUgaGVhbHRoIG9mIHRoZSBvdGhlciBzZXJ2aWNlLg0KPiA+IEkuZS4gdXNpbmcgSVAgQkZEIHRv IGluZm9ybSBMQUNQIG9yIEV0aGVybmV0IEJGRCB0byBpbmZvcm0gSVAgZm9yd2FyZGluZw0KPiA+ IGhlYWx0aC4NCj4gPg0KPiA+IFRodXMsIGlmIHdlJ3JlIHdhbnRpbmcgdG8gdmVyaWZ5IHRoYXQg SVAgdW5pY2FzdCB0cmFmZmljIGlzIGNvcnJlY3RseSBiZWluZw0KPiANCj4gQVMgaSBtZW50aW9u ZWQgZWFybGllciwgSSB0aGluayB3ZSdsbCBiZSB2ZXJ5IG15b3BpYyBpZiB3ZSByZXN0cmljdA0K PiBvdXJzZWx2ZXMgdG8gSVAgdW5pY2FzdCB0cmFmZmljLiBXaGF0IHByZXZlbnRzIHVzIGZyb20g dXNpbmcgdGhhdCBsaW5rDQo+IGZvciBtdWx0aWNhc3QgdHJhZmZpYyBvciBMMiB0cmFmZmljPw0K PiANCj4gPiBmb3J3YXJkZWQgYWNyb3NzIGEgTEFHIGVsZW1lbnQsIEJGRCBzaG91bGQgYmUgc2Vu dCBhcyBJUCB1bmljYXN0LiDCoEFtb25nDQo+ID4gb3RoZXIgdGhpbmdzLCB3ZSdsbCBiZSB1c2lu ZyB0aGUgc2FtZSBNQUMuIMKgSWYgd2Ugd2VyZSBpbnN0ZWFkIHRvIGJlIHVzaW5nDQo+ID4gSVAg bXVsdGljYXN0IGZvciBCRkQsIHRoZSBNQUMgd2lsbCBiZSBkaWZmZXJlbnQgYW5kIHRoZSBmYXRl IG9mIHRoZSBCRkQNCj4gPiBzZXNzaW9uIGlzIGxlc3Mgc3Ryb25nbHkgY291cGxlZCB0byB0aGUg YWJpbGl0eSB0byBwcm9wZXJseSBmb3J3YXJkIHRoZQ0KPiA+IHRyYWZmaWMuDQo+IA0KPiBJIHRo aW5rIG1pY3JvIEJGRCBzZXNzaW9ucyBhcmUgcmVxdWlyZWQgZm9yIHJlcXVpcmVkIGZvciBsaW5r DQo+IGxpdmVsaW5lc3MgYW5kIG5vdCBJUCBsaXZlbGluZXNzLiBJZiBvbiBvcGVyYXRvciB3YW50 cyB0byBlbnN1cmUgSVANCj4gbGF5ZXIgbGl2ZWxpbmVzcyB0aGVuIHRoZXkgbXVzdCBydW4gQkZE IGluIHRoZSBCaWcgUGlwZSBtb2RlDQo+IChkZXNjcmliZWQgaW4gU2VjIDQsIGJ1bGxldCAiYiIp LiBUaGUgbWljcm8gQkZEIHNlc3Npb25zIHdvcmsgYWxvbmcNCj4gd2l0aCBMQUNQIHRvIGluZm9y bSB0aGUgTEFHIG1hbmFnZXIgb2YgdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGxpbmtzDQo+IGlu IHRoZSBMQUcuIFRoZXkgYXJlIG5vdCBtZWFudCBmb3IgSVAgY29ubmVjdGl2aXR5LiBNYW5hdiBh bmQgTWFyYyAtIEkNCj4gaG9wZSBpIGFtIG5vdCB0b28gbXVjaCBvZmYgdGhlIG1hcmshDQo+IA0K PiBCQlAgKFNlYyAyLjEpIHVzZXMgSVAgZW5jYXBzdWxhdGlvbiB3aGljaCBpcyBmaW5lIGFzIGl0 cyB0aGlzIHRoYXRzDQo+IG1lYW50IGZvciBJUCBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uLg0K PiANCj4gPg0KPiA+IFRoaXMgaXNuJ3QgdG8gc2F5IHRoYXQgSSBkb24ndCBhZ3JlZSBub3Igc3lt cGF0aGl6ZSB3aXRoIHRoZSBpc3N1ZXMNCj4gPiBkb2N1bWVudGVkIGluIEFwcGVuZGl4IEEgb2Yg dGhlIGRyYWZ0LiDCoE11bHRpY2FzdCBkb2VzIG1ha2UgdGhpbmdzDQo+ID4gKnNpZ25pZmljYW50 bHkqIGVhc2llci4NCj4gDQo+IFdoaWNoIGlzIHdoeSBpIHdhcyBlYXJsaWVyIHJvb3RpbmcgZm9y IG11bHRpY2FzdC4gSG93ZXZlciwgcmVjZW50DQo+IGRpc2N1c3Npb25zIG9uIHRoZSBsaXN0IGhh dmUgZ290IG1lIHRoaW5raW5nIGFuZCBpIHRoaW5rIGkgbWF5DQo+IGRyaWZ0aW5nIHRvd2FyZHMg QkZEIG92ZXIgcHVyZSBMMiBlbmNhcCBtb2RlIG5vdy4NCj4gDQo+ID4NCj4gPiBUbyB0YWtlIGEg c3RlcCBiYWNrLCB0aGUgcHJvYmxlbSBzcGFjZSBJIGJlbGlldmUgd2UncmUgdHJ5aW5nIHRvIGFk ZHJlc3MgaW4NCj4gPiB0aGUgSUVURiAocmF0aGVyIHRoYW4gaW4gSUVFRSkgaXMgdGhlIGZhY3Qg dGhhdCBJUCBmb3J3YXJkaW5nIG1heSBmYWlsDQo+ID4gYmVjYXVzZSBlbGVtZW50cyBvZiBhIExB RyBhcmUgbm90IGJlaW5nIHRha2VuIGRvd24gZmFzdCBlbm91Z2guDQo+IA0KPiBOby4gSSB0aGlu ayB0aGlzIGlzIHRoZSBkaXNjb25uZWN0LiBJdHMgbWVhbnQgdG8gZGV0ZWN0IGZhc3QgbGluayBm YWlsdXJlcy4NCj4gDQo+ID4NCj4gPiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCBhIHBlciBsaW5rIEJG RCBzb2x1dGlvbiBuZWVkcyB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6DQo+ID4gLSBVc2VzIGFu IGVuY2Fwc3VsYXRpb24gbWVhbnQgdG8gZXhlcmNpc2UgdGhlIGZvcndhcmRpbmcgcGF0aCBvZiB0 aGUgdHJhZmZpYw0KPiA+IMKgaXQgaXMgbWVhbnQgdG8gcHJvdGVjdC4gwqBUaGlzIGlzIGNvbnNp c3RlbnQgd2l0aCB0aGUgb3JpZ2luYWwgZGVzaWduIG9mDQo+ID4gwqBCRkQuDQo+ID4gLSBTSE9V TEQgTk9UIGFsdGVyIHRoZSBjb3JlIEJGRCBzdGF0ZSBtYWNoaW5lIGlmIGF0IGFsbCBwb3NzaWJs ZS4gwqBFLmcuLA0KPiBNUExTLVRQDQo+ID4gwqBoYWQgZ29vZCByZWFzb25zIHRvIHZhcnkgaXQg aW4gc29tZSBjaXJjdW1zdGFuY2VzLCBidXQgd2FzIHB1c2hlZCB0byBiZQ0KPiA+IMKgY29tcGxp YW50IHdoZW4gY2lyY3Vtc3RhbmNlcyBkaWQgbm90IHJlcXVpcmUgdGhlIGRldmlhdGlvbi4NCj4g PiAtIElmIHRoZSBzZXNzaW9uIGJvb3RzdHJhcHBpbmcgbWVjaGFuaXNtIGRldmlhdGVzIGZyb20g UkZDIDU4ODAvNTg4MSwgaXQNCj4gPiDCoE1VU1QgTk9UIGNhdXNlIGludGVyb3BlcmFiaWxpdHkg aXNzdWVzIHdpdGggQkZEIHNlc3Npb25zIG9uIG5vbi1MQUcNCj4gbGlua3MuDQo+ID4gwqAoSS5l LiBhIGRpZmZlcmVudCBVRFAgZGVzdGluYXRpb24gcG9ydC4pDQo+IA0KPiBUaGlzIG1lYW5zIHRo YXQgeW91IGFzc3VtZSB0aGF0IEJGRCBvbmx5IHdvcmtzIGluIG1vZGUgZGVzY3JpYmVkIGluDQo+ IFNlYyA0LCBidWxsZXQgImEiLg0KPiANCj4gSSBhbSBub3Qgc3VyZSBpZiB0aGlzIHdhcyBkaXNj dXNzZWQuDQo+IA0KPiA+IC0gV2Ugbm93IG5lZWQgYSBwZXItbGluayBib290c3RyYXBwaW5nIG1l Y2hhbmlzbSBkaWZmZXJlbnQgZnJvbSB0aGUNCj4gZXhpc3RpbmcNCj4gPiDCoFJGQyA1ODgwLzU4 ODEuDQo+ID4gLSBCRkQgZG9uZSBvbiBhIHRyYWRpdGlvbmFsIGhvc3QgKHJvdXRpbmcgcHJvY2Vz c29yL3JvdXRpbmcgZW5naW5lL2V0Yy4pDQo+ID4gwqBpbnN0ZWFkIG9mIGF0IHRoZSBsaW5lIGNh cmQgbGV2ZWwgYmVjb21lcyBtZXNzeSBkdWUgdG8gbGF5ZXJpbmcgaXNzdWVzLg0KPiA+IMKgKEku ZS4gImhlcmUncyBJUCBkZXN0aW5lZCBmb3IgdGhpcyBob3N0LCBwbGVhc2UgaWdub3JlIHRoZSBy b3V0aW5nDQo+ID4gwqB0YWJsZSIuKSDCoEhvd2V2ZXIsIEkgZG9uJ3QgdGhpbmsgdGhpcyBwcm9i bGVtIGlzIHRlcnJpYmx5IG11Y2ggd29yc2UgdGhhbg0KPiA+IMKgSVMtSVMgb3IgVlJSUCBvbiBz dWNoIGhvc3RzLiDCoChJIGFncmVlIHRoYXQgaXQgaXMgc3RpbGwgZ3Jvc3MuKQ0KPiANCj4gSVMt SVMgdXNlcyBhIHdlbGwga25vd24gTDIgYWRkcmVzcyBzbyBpdHMgcmVhbGx5IG5vdCBhIHZpb2xh dGlvbi4NCj4gDQo+ID4NCj4gPiBJJ2QgbGlrZSB1cyB0byBzZWUgYSBiaXQgbW9yZSBkaXNjdXNz aW9uIGFyb3VuZCByZXF1aXJlbWVudHMgYmVmb3JlDQo+ID4gY29tcGxldGVseSBkaXZpbmcgaW50 byBzb2x1dGlvbnMuIMKgSG93ZXZlciwgSSB0aGluayB0aGUgZGlzY3Vzc2lvbiBhcm91bmQNCj4g PiB0aGUgc29sdXRpb25zIGhhcyBoZWxwZWQgdG8gY2xhcmlmeSB0aGUgaXNzdWVzIGFuZCB0aGUg ZHJhZnQgaGFzIGRvbmUgYSBnb29kDQo+ID4gam9iIG9uIGRyaXZpbmcgdGhhdCBkaXNjdXNzaW9u Lg0KPiANCj4gWWVzLCBpIGFncmVlLiBXZSBhbGwgYXBwcmVjaWF0ZSB0aGUgd29yayBkb25lIGJ5 IHRoZSBhdXRob3JzIG9mDQo+IGRyYWZ0LW1tbS1iZmQtb24tbGFncyBhbmQgaXRzIGRlZmluaXRl bHkgaGVscGVkIGNsZWFyIHRoZSBmb2cNCj4gc3Vycm91bmRpbmcgdGhlIHByb2JsZW0gYW5kIHRo ZSBzb2x1dGlvbiBzcGFjZS4NCj4gDQo+IEkgd291bGQgdXJnZSB0aGUgZm9sa3MgdG8gZmlyc3Qg ZGlzY3VzcyB3aGV0aGVyIGl0cyB0byBiZSBMMiBvciBMMywNCj4gYmVmb3JlIGdldHRpbmcgaW50 byB0aGUgc3BlY2lmaWNzIG9mIHdoZXRoZXIgaXQgc2hvdWxkIGJlIFVuaWNhc3Qgb3INCj4gTXVs dGljYXN0Lg0KPiANCj4gLS0NCj4gVG9tcw0K From mach.chen@huawei.com Mon Jan 9 02:03:24 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBA021F8468 for ; Mon, 9 Jan 2012 02:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 4EJkD-alO1+D for ; Mon, 9 Jan 2012 02:03:24 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BB4BB21F8421 for ; Mon, 9 Jan 2012 02:03:23 -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 <0LXI00ECVZKL2P@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Mon, 09 Jan 2012 17:55:33 +0800 (CST) Received: from szxrg02-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 <0LXI004T6ZKLF1@szxga04-in.huawei.com> for rtg-bfd@ietf.org; Mon, 09 Jan 2012 17:55:33 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGF07188; Mon, 09 Jan 2012 17:55:33 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 09 Jan 2012 17:55:30 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.67]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Mon, 09 Jan 2012 17:55:24 +0800 Date: Mon, 09 Jan 2012 09:55:24 +0000 From: Mach Chen Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) In-reply-to: X-Originating-IP: [10.108.4.53] To: Jeff Tantsura , Jeffrey Haas , "rtg-bfd@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-index: AQHMzpdunHM9Rk11Qk6h1Dtg32IEnJYDyOiQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120109022815.GN7464@slice> X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 10:03:24 -0000 Hi Jeff, For L3 solution, based on our experience, the implementation difference is trivial between unicast and multicast, but with multicast, as summarized in the Appendix, it has many merits (e.g., no extra configurations/bootstrapping mechanisms required) but unicast has not. I think the WG should firstly focus on discussing whether L2 or L3 solution is the right direction. Best regards, Mach > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of > Jeff Tantsura > Sent: Monday, January 09, 2012 2:25 PM > To: Jeffrey Haas; rtg-bfd@ietf.org > Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD > on LAG interfaces)) > > I completely agree with Jeff's position here, my proposal is again to use > unicast IP, it addresses both single and multi session BFD over LAG while > requres minimum changes to the existing implementations, keep in mind - > any new implementation should still be interoperable with "legacy" BFD > over LAG, being RP or LC based, so no changes such as another/new UDP port. > > BFD is an IP protocol and should not be used on L2 LAG implementations, I > have already described in my previous mail how IMHO messaging with > internal structures should look like (RIB/etc) > -- > Regards, > Jeff > > > > > > > On 1/8/12 6:28 PM, "Jeffrey Haas" wrote: > > >[Speaking currently as an individual contributor.] > > > >I believe that Appendix A does a very nice job in summarizing many of the > >issues accompanying each of the varying proposed solutions. However, in > >catching up on the full set of threads for this topic, I have to wonder if > >we're conflating two highly related set of requirements that should be > >analyzed separately. > > > >Our fundamental problem is that ethernet LAGs, e.g. when using LACP, may > >blackhole traffic for large periods of time due to convergence issues in > >that protocol. Similarly, such blackholing may exist when a LAG is > >statically configured. > > > >(Clearly such issues would exist for other forms of LAGs, but our primary > >discussion has centered around Ethernet. I will largely restrict this > >response to that problem space.) > > > >It is fair to observe that in the case of LAGs managed by LACP that the > >real > >problem is it converges too slow. This is something that could be > >addressed > >by IEEE. BFD, running as an application on top of Ethernet, could be used > >to inform an LACP implementation to converge faster. IMO, in such a case, > >Ethernet encapsulation of BFD makes a lot of sense. > > > >BFD provides its functionality by exercising the forwarding path. In the > >case of a LAG used for IP, the functionality we want to see is that when a > >link is up, it is forwarding IP traffic. To me, this frames the > >requirements somewhat differently than the prior discussion although many > >of > >the same observations still hold. > > > >Where I believe we're conflating the issues is using BFD in one > >encapsulation, IP or Ethernet, to test the health of the other service. > >I.e. using IP BFD to inform LACP or Ethernet BFD to inform IP forwarding > >health. > > > >Thus, if we're wanting to verify that IP unicast traffic is correctly > >being > >forwarded across a LAG element, BFD should be sent as IP unicast. Among > >other things, we'll be using the same MAC. If we were instead to be using > >IP multicast for BFD, the MAC will be different and the fate of the BFD > >session is less strongly coupled to the ability to properly forward the > >traffic. > > > >This isn't to say that I don't agree nor sympathize with the issues > >documented in Appendix A of the draft. Multicast does make things > >*significantly* easier. > > > >To take a step back, the problem space I believe we're trying to address > >in > >the IETF (rather than in IEEE) is the fact that IP forwarding may fail > >because elements of a LAG are not being taken down fast enough. > > > >I would suggest that a per link BFD solution needs the following > >properties: > >- Uses an encapsulation meant to exercise the forwarding path of the > >traffic > > it is meant to protect. This is consistent with the original design of > > BFD. > >- SHOULD NOT alter the core BFD state machine if at all possible. E.g., > >MPLS-TP > > had good reasons to vary it in some circumstances, but was pushed to be > > compliant when circumstances did not require the deviation. > >- If the session bootstrapping mechanism deviates from RFC 5880/5881, it > > MUST NOT cause interoperability issues with BFD sessions on non-LAG > >links. > > (I.e. a different UDP destination port.) > >- SHOULD be port-centric. This means a session should not use a return > >path > > that does not exercise the path to be verified for that session. While > > this is fine for traditional IP BFD, per link BFD with IP encapsulation > > taking the wrong return path would leave it in question whether it was > >the > > forward path or the reverse path that were damaged. > >- MAY be used as inputs to an aggregated BFD session state between the two > > systems. > > > >As I mentioned above, I'm very sympathetic with the issues that such > >requirements would place upon an implementor. There are at least two > >classes of issues here: > >- We now need a per-link bootstrapping mechanism different from the > >existing > > RFC 5880/5881. > >- BFD done on a traditional host (routing processor/routing engine/etc.) > > instead of at the line card level becomes messy due to layering issues. > > (I.e. "here's IP destined for this host, please ignore the routing > > table".) However, I don't think this problem is terribly much worse > >than > > IS-IS or VRRP on such hosts. (I agree that it is still gross.) > > > >I'd like us to see a bit more discussion around requirements before > >completely diving into solutions. However, I think the discussion around > >the solutions has helped to clarify the issues and the draft has done a > >good > >job on driving that discussion. > > > >-- Jeff From marc@sniff.de Mon Jan 9 02:45:08 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5F421F8673 for ; Mon, 9 Jan 2012 02:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 G5HEI2C7g2-w for ; Mon, 9 Jan 2012 02:45:08 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6730A21F8475 for ; Mon, 9 Jan 2012 02:45:07 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id C02362AA0F; Mon, 9 Jan 2012 10:45:04 +0000 (GMT) Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was 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, 9 Jan 2012 11:44:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6EB8B0DB-5DD8-41C7-9C9E-F4A7D27B1C1E@sniff.de> References: To: Jeff Tantsura 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: Mon, 09 Jan 2012 10:45:08 -0000 Hello Jeff, > keep in mind - > any new implementation should still be interoperable with "legacy" BFD > over LAG, being RP or LC based, so no changes such as another/new UDP = port. Are you talking about the existing, proprietary BFD-on-member-link = implementations when you refer to "legacy BFD over LAG"? While it is = desirable for the particular companies to minimize the change we cannot = make backward compatibility a requirement.=20 And personally, _if_ we end up with unicast IP (we talk about the IP = address configured on the LAG, I assume?) and want to use the aggregator = MAC then I would very much like to see a different UDP port. Reason is = section 4, case (b) in the draft-mmm. If you talk about the single BFD over LAG (what is named BFD over Big = Pipe in draft-mmm) then I agree, this BFD session should be = RFC5880/RFC5881 with no modification. Regards, Marc On 2012-01-09, at 7:24 , Jeff Tantsura wrote: > I completely agree with Jeff's position here, my proposal is again to = use > unicast IP, it addresses both single and multi session BFD over LAG = while > requres minimum changes to the existing implementations, keep in mind = - > any new implementation should still be interoperable with "legacy" BFD > over LAG, being RP or LC based, so no changes such as another/new UDP = port. >=20 > BFD is an IP protocol and should not be used on L2 LAG = implementations, I > have already described in my previous mail how IMHO messaging with > internal structures should look like (RIB/etc) > --=20 > Regards, > Jeff >=20 >=20 >=20 >=20 >=20 >=20 > On 1/8/12 6:28 PM, "Jeffrey Haas" wrote: >=20 >> [Speaking currently as an individual contributor.] >>=20 >> I believe that Appendix A does a very nice job in summarizing many of = the >> issues accompanying each of the varying proposed solutions. However, = in >> catching up on the full set of threads for this topic, I have to = wonder if >> we're conflating two highly related set of requirements that should = be >> analyzed separately. >>=20 >> Our fundamental problem is that ethernet LAGs, e.g. when using LACP, = may >> blackhole traffic for large periods of time due to convergence issues = in >> that protocol. Similarly, such blackholing may exist when a LAG is >> statically configured. >>=20 >> (Clearly such issues would exist for other forms of LAGs, but our = primary >> discussion has centered around Ethernet. I will largely restrict = this >> response to that problem space.) >>=20 >> It is fair to observe that in the case of LAGs managed by LACP that = the >> real >> problem is it converges too slow. This is something that could be >> addressed >> by IEEE. BFD, running as an application on top of Ethernet, could be = used >> to inform an LACP implementation to converge faster. IMO, in such a = case, >> Ethernet encapsulation of BFD makes a lot of sense. >>=20 >> BFD provides its functionality by exercising the forwarding path. In = the >> case of a LAG used for IP, the functionality we want to see is that = when a >> link is up, it is forwarding IP traffic. To me, this frames the >> requirements somewhat differently than the prior discussion although = many >> of >> the same observations still hold. >>=20 >> Where I believe we're conflating the issues is using BFD in one >> encapsulation, IP or Ethernet, to test the health of the other = service. >> I.e. using IP BFD to inform LACP or Ethernet BFD to inform IP = forwarding >> health. >>=20 >> Thus, if we're wanting to verify that IP unicast traffic is correctly >> being >> forwarded across a LAG element, BFD should be sent as IP unicast. = Among >> other things, we'll be using the same MAC. If we were instead to be = using >> IP multicast for BFD, the MAC will be different and the fate of the = BFD >> session is less strongly coupled to the ability to properly forward = the >> traffic. >>=20 >> This isn't to say that I don't agree nor sympathize with the issues >> documented in Appendix A of the draft. Multicast does make things >> *significantly* easier. >>=20 >> To take a step back, the problem space I believe we're trying to = address >> in >> the IETF (rather than in IEEE) is the fact that IP forwarding may = fail >> because elements of a LAG are not being taken down fast enough. >>=20 >> I would suggest that a per link BFD solution needs the following >> properties: >> - Uses an encapsulation meant to exercise the forwarding path of the >> traffic >> it is meant to protect. This is consistent with the original design = of >> BFD. =20 >> - SHOULD NOT alter the core BFD state machine if at all possible. = E.g., >> MPLS-TP >> had good reasons to vary it in some circumstances, but was pushed to = be >> compliant when circumstances did not require the deviation. >> - If the session bootstrapping mechanism deviates from RFC 5880/5881, = it >> MUST NOT cause interoperability issues with BFD sessions on non-LAG >> links. >> (I.e. a different UDP destination port.) >> - SHOULD be port-centric. This means a session should not use a = return >> path >> that does not exercise the path to be verified for that session. = While >> this is fine for traditional IP BFD, per link BFD with IP = encapsulation >> taking the wrong return path would leave it in question whether it = was >> the >> forward path or the reverse path that were damaged. >> - MAY be used as inputs to an aggregated BFD session state between = the two >> systems. >>=20 >> As I mentioned above, I'm very sympathetic with the issues that such >> requirements would place upon an implementor. There are at least two >> classes of issues here: >> - We now need a per-link bootstrapping mechanism different from the >> existing >> RFC 5880/5881. =20 >> - BFD done on a traditional host (routing processor/routing = engine/etc.) >> instead of at the line card level becomes messy due to layering = issues. >> (I.e. "here's IP destined for this host, please ignore the routing >> table".) However, I don't think this problem is terribly much worse >> than >> IS-IS or VRRP on such hosts. (I agree that it is still gross.) >>=20 >> I'd like us to see a bit more discussion around requirements before >> completely diving into solutions. However, I think the discussion = around >> the solutions has helped to clarify the issues and the draft has done = a >> good >> job on driving that discussion. >>=20 >> -- Jeff >=20 -- Marc Binderberger From marc@sniff.de Mon Jan 9 03:02:26 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9221F868C for ; Mon, 9 Jan 2012 03:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 yovhkMC4sFF5 for ; Mon, 9 Jan 2012 03:02:14 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1C721F852F for ; Mon, 9 Jan 2012 03:02:13 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id CD9892AA0F; Mon, 9 Jan 2012 11:02:11 +0000 (GMT) Subject: Re: Multicast vs Unicast (was 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, 9 Jan 2012 12:02:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <07D139AE-1673-47B4-83B8-C47E69370A33@sniff.de> References: , To: Robert Rennison , Alexander Vainshtein , Pablo Frank 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: Mon, 09 Jan 2012 11:02:26 -0000 Hello Alexander, > Please note also that if micro-BFD sessions are used in conjunction = with LACP, there is also no need for a new well-known multicast MAC = address, you can use MAC address of the peer port - learned via LACP - = as the destination address (and, of course, the local port MAC address = as the source address). true but it binds the solution to LACP as a must-have. While I agree = that LACP is usually used by the customers it also means we have to = invent another solution for the few customers that don't use LACP (for = whatever reason). Requesting a well-known MAC is just clean to me for the layer-2 = solution. Regarding layer-2 vs. layer-3: I agree the first thought may be "BFD in = Ethernet" when looking at the problem. And nothing wrong with it. The = layer-3 topic comes from additional "requirements" from customers that = want to see BFD is related to layer-3 processing. So we try to square a = circle (or circle a square?). Regards, Marc On 2012-01-09, at 7:05 , Alexander Vainshtein wrote: > Rob, Pablo and all, >=20 > I concur with Rob: BFD on LAG members using a dedicated Ethertype and = used as an accelerator for LACP detecting the failures of LAG members = looks like the right thing to do. >=20 > Please note also that if micro-BFD sessions are used in conjunction = with LACP, there is also no need for a new well-known multicast MAC = address, you can use MAC address of the peer port - learned via LACP - = as the destination address (and, of course, the local port MAC address = as the source address). >=20 > As Jeff has indicated in one of his messages on this thread = (http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01204.html), = the operators tend to use LACP with LAG in any case. As for the = exceptions Jeff has mentioned, IMHO "oldish gear" is not very relevant = (it would not support BFD as well). This leaves "extremely buggy LACP = implementations"... but I do not believe that providing workaround for = someone's bugs is an important objective. >=20 > My 2c, > Sasha >=20 > ________________________________________ > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of = Robert Rennison [robrennison@gmail.com] > Sent: Wednesday, January 04, 2012 10:39 PM > To: Pablo Frank > Cc: rtg-bfd@ietf.org > Subject: Re: Multicast vs Unicast (was BFD on LAG interfaces) >=20 > Pablo I agree, I am sensing a lot of over-engineering going on in some > of the discussions re encapsulations, my gut feel going when I saw the > thread start was, it will quickly settle on using a new Ethertype. >=20 > I lost track of or was never really convinced of what concrete reason > folks would want to be using anything other than an L2 encaps, for > example the individual links do not have an IP address on them so then > there were debates about using IP mcast addresses and demuxing on port > , yeuch. >=20 > So on the K.I.S.S principle my vote goes too for trying to getting a > new Ethertype and do not try to get a spec allowing a multiple of > encaps as this has the potential to balloon out of all proportion. >=20 > Cheers >=20 > Rob Rennison >=20 > P.s I am also a fan of sticking to having BFD be an adjunct to or an > accelerator for LACP so have the micro flow or per interface BFD > sessions provide an early indication to LACP that there is a problem > with the link. One still potentially needs an overarching slower per > LAG group BFD session to keep the upper layers happy if they are > expecting BFD on the IP interface. I say potentially because if the > interface is now protected by an augmented LACP perhaps the upper > layers do not need an explicit BFD, that's a more nuanced discussion. >=20 >=20 > On Wed, Jan 4, 2012 at 11:12 AM, Pablo Frank = wrote: >> I know there's been some arguments made in favour of option 1 that >> suggest that existing ASICs may be better able to handle >> IP-encapsulated BFD. Frankly, most vendors are using flexible-enough >> parsing hardware so I'm not sure this is a very strong argument >> anymore. So I decided to focus on just looking at it from a pure >> software IP-stack perspective. >>=20 >> It seems that either variant of option 1 requires an implementer to = do >> some pretty ugly hacking to get around existing stack = implementations. >> I tried getting 1a to work using standard Linux socket APIs and ran >> into all sorts of problems. The fundamental issue is that the member >> links of a LAG are not normally IP-enabled so trying to bind an IP >> multicast group membership didn't work. The other issue was trying = to >> force the UDP frames out a particular underlying member link was not >> possible using the existing socket options for UDP sockets. The only >> way I got it to work was using AF_PACKET raw sockets and setting up >> some Berkeley Packet Filters to filter out the frames with the = correct >> L2 multicast MAC address, ethertype, and L3 multicast IP address >> (since L2 multicast address is not specific enough). But in this >> case, I'm essentially bypassing the IP stack so I don't get to >> benefit-from/reuse any of the normal IP stack capabilities (i.e. no = IP >> header validation, checksum checking, etc.). This was really ugly. = I >> didn't even try 1b. >>=20 >> Option 2, on the other hand, was trivially easy using AF_PACKET DGRAM >> sockets. It was very straightforward to bind the TBA ethertype, the >> TBA multicast MAC, and the interface to use. >>=20 >> The fact that option 1 was so convoluted isn't surprising given the >> obvious layering violations that are taking place here. So unless >> there are gigantic barriers in place to prevent us from getting a MAC >> address and ethertype assigned for this kind of low-level BFD, I = don't >> think we should really be seriously considering either variant of >> option 1. >>=20 >> regards, >> Pablo >>=20 >>> The two options before the WG are: >>>=20 >>> 1. Use IP encapsulation >>> 2. Use direct L2 encapsulation. >>>=20 >>> With (1) we have an option of (1a) Using Multicast and (1b) Using = Unicast. >>>=20 >>> Can we arrive on a consensus between choosing 1a and 1b? >>>=20 >>> 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. >>>=20 >>> Lets try closing the different threads so that we can converge = towards >>> a solution. >>>=20 >>> Toms >=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 Alexander.Vainshtein@ecitele.com Mon Jan 9 03:08:59 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DE921F8704 for ; Mon, 9 Jan 2012 03:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.563 X-Spam-Level: X-Spam-Status: No, score=-4.563 tagged_above=-999 required=5 tests=[AWL=0.640, 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 dr0evtQnQfKe for ; Mon, 9 Jan 2012 03:08:55 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 1CD5321F86E5 for ; Mon, 9 Jan 2012 03:08:52 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1326104955!55139942!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 30343 invoked from network); 9 Jan 2012 10:29:17 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-4.tower-27.messagelabs.com with SMTP; 9 Jan 2012 10:29:17 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-98-4f0ac299535a Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 8D.C5.08306.992CA0F4; Mon, 9 Jan 2012 12:34:01 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 9 Jan 2012 12:29:55 +0200 From: Alexander Vainshtein To: Mach Chen Date: Mon, 9 Jan 2012 12:29:54 +0200 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AQHMzpdunHM9Rk11Qk6h1Dtg32IEnJYDyOiQgAAGU7A= Message-ID: References: <20120109022815.GN7464@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTXUwUVxjNnZldhoVpxkW6F/Rhey1NUdaAYLK6rNb4gkaDTX8eIGYdZq+7 E3dnJzuzxOUFMBgNKrEVrG4krkosbSFQUhGiYqAEswTRSlQqtprIA39bErBRkYgzTKUY5+nM d875zr0330eT5kMJ6bQgKjgocj5kNFGnJmae2872mAqzbz1C9tontwz2m91xg/1uc4p9dr4d fEEVzP1731hQ1Rs3FDQ0vCIKhk5cMeyhiipAPieKAYVTsNWNZd6J9gSFUo4PI6vgdqIcZJV8 HI/9WFSciJMkLLrRFpP1gy9flQmiFYt8wC2IHifa8VWhzW7fuMmWg7Z8tiYn12H62ivIVmzz c4LP6seyzHmwVa3s+430DvzRR0q3tx8cab1KVIDZvGqQSEM2D07/U0fo+GN49+8WYzUw0Wa2 E8CK63cMGmFmTwE4NOLSsJF1wrZf/jJqeCX7KTw93pygYZIthXNjN4CGKbV+piOyiFNYDk5e ukjo+hL4/VAb0PFm2NpYs9iHYb+Ex9tngR58EcAXC/2kRiSy38KZc78vYqCe7kV/E6GHWeCj 0fP/nZqFDdfvkDpOhePP3hh0fSp8fKQF6PosGL02Y9TxOnj5wiSpB6+AsbOjlO5Ng92Nw9RJ YIksi4gss0eW2SPL7FFA/QzSBJ+klPg92RtsgZCyHvOCgn14PR/wtwF9dsY6wMhAZg9gaYCS GbjdVGg2cKVy2N8D0mgCpTLlN9XSRyUBd9jLyV5XMOTDcg+ANIlWMuEalWPcXLgMBwPvKLv6 1N+R6Ul8QJ1SUXHlZme/94MszDF+areZ9aiTdwBjCQffWVfTNIJMRrfadUUQe/DB/YJP+Z8m 6EQtOVlNdmkaRpY4vyx4dL4f5NIPK+sHAT34Q3QQmCkxIOJ0C5OnSVlN6g2JS9201SlfWFiY ABb15ilMkaZKVhdrqd+EGkWoUU/nE7QodU+WqPQKcPtl7JtRofESzz0plnL7z/T9uu2YY/+1 2K6a2r1bO1xrLpfsjj2ovVBVF25M3VmXlR+tOl8dR6Ga6lXU4bk/HY4bJ5vShpu64mUJTzN+ iqeMdE4loaJ7WcWZ9Y+7urqmo44fk9yOjcX10jABX/fOPCful4U+aT6a5xqo/DzTXhlDlOzl ctaSQZl7C0hZvhgVBAAA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:08:59 -0000 Mach and all, One rather obvious problem with the IP-based encapsulation (multicast or uni= cast) is IMHO that it is a clear layer violation. Pablo has already commented on implementation problems with this approach in= his message ( http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01207= .html) and their origin in the said layer violation. I also have certain doubts interpreting the statements like " BFD provides i= ts functionality by exercising the forwarding path" in Jeffrey's message (ht= tp://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01212.html ). The forwarding path for IP traffic sent treats LAG as the interface (or, in= the 802.1AX terms, IP is a client of the LAG MAC - see Figure 5.3 in the IE= EE 802.1AX-2008). This means that: - Source MAC address of IP packets transmitted via LAGF is MAC address of th= e LAG (does not depend on the specific LAG member over which it is actually= transmitted) - Destination MAC address of the unicast IP packet is MAC address of the pee= r LAG (discovered via ARP for IPv4 or ND for IPv6) - IP layer does not exercise any kind of explicit control over selection of= the LAG member over which the packet. Instead selection is done by the LAG= distributor. In fact, with most distributors, all BFD packets would be tra= nsmitted via a single LAG member link because they would be identified as be= longing to the same flow. And BFD that exercises this forwarding path is wha= t draft-mmm calls the "Big Pipe BFD session". (BTW, Big Pipe BFD that distr= ibute BFD packets over all LAG members actually exercise a different forward= ing path). Did I miss something? Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Mach Chen > Sent: Monday, January 09, 2012 11:55 AM > To: Jeff Tantsura; Jeffrey Haas; rtg-bfd@ietf.org > Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was > BFD on LAG interfaces)) > > Hi Jeff, > > For L3 solution, based on our experience, the implementation difference is > trivial between unicast and multicast, but with multicast, as summarized i= n > the Appendix, it has many merits (e.g., no extra > configurations/bootstrapping mechanisms required) but unicast has not. > > I think the WG should firstly focus on discussing whether L2 or L3 solutio= n is > the right direction. > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of > > Jeff Tantsura > > Sent: Monday, January 09, 2012 2:25 PM > > To: Jeffrey Haas; rtg-bfd@ietf.org > > Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was > BFD > > on LAG interfaces)) > > > > I completely agree with Jeff's position here, my proposal is again to us= e > > unicast IP, it addresses both single and multi session BFD over LAG whil= e > > requres minimum changes to the existing implementations, keep in mind > - > > any new implementation should still be interoperable with "legacy" BFD > > over LAG, being RP or LC based, so no changes such as another/new UDP > port. > > > > BFD is an IP protocol and should not be used on L2 LAG implementations,= I > > have already described in my previous mail how IMHO messaging with > > internal structures should look like (RIB/etc) > > -- > > Regards, > > Jeff > > > > > > > > > > > > > > On 1/8/12 6:28 PM, "Jeffrey Haas" wrote: > > > > >[Speaking currently as an individual contributor.] > > > > > >I believe that Appendix A does a very nice job in summarizing many of > the > > >issues accompanying each of the varying proposed solutions. However, > in > > >catching up on the full set of threads for this topic, I have to wonder= if > > >we're conflating two highly related set of requirements that should be > > >analyzed separately. > > > > > >Our fundamental problem is that ethernet LAGs, e.g. when using LACP, > may > > >blackhole traffic for large periods of time due to convergence issues i= n > > >that protocol. Similarly, such blackholing may exist when a LAG is > > >statically configured. > > > > > >(Clearly such issues would exist for other forms of LAGs, but our prima= ry > > >discussion has centered around Ethernet. I will largely restrict this > > >response to that problem space.) > > > > > >It is fair to observe that in the case of LAGs managed by LACP that the > > >real > > >problem is it converges too slow. This is something that could be > > >addressed > > >by IEEE. BFD, running as an application on top of Ethernet, could be u= sed > > >to inform an LACP implementation to converge faster. IMO, in such a > case, > > >Ethernet encapsulation of BFD makes a lot of sense. > > > > > >BFD provides its functionality by exercising the forwarding path. In t= he > > >case of a LAG used for IP, the functionality we want to see is that whe= n a > > >link is up, it is forwarding IP traffic. To me, this frames the > > >requirements somewhat differently than the prior discussion although > many > > >of > > >the same observations still hold. > > > > > >Where I believe we're conflating the issues is using BFD in one > > >encapsulation, IP or Ethernet, to test the health of the other service. > > >I.e. using IP BFD to inform LACP or Ethernet BFD to inform IP forwardin= g > > >health. > > > > > >Thus, if we're wanting to verify that IP unicast traffic is correctly > > >being > > >forwarded across a LAG element, BFD should be sent as IP unicast. > Among > > >other things, we'll be using the same MAC. If we were instead to be > using > > >IP multicast for BFD, the MAC will be different and the fate of the BFD > > >session is less strongly coupled to the ability to properly forward the > > >traffic. > > > > > >This isn't to say that I don't agree nor sympathize with the issues > > >documented in Appendix A of the draft. Multicast does make things > > >*significantly* easier. > > > > > >To take a step back, the problem space I believe we're trying to addres= s > > >in > > >the IETF (rather than in IEEE) is the fact that IP forwarding may fail > > >because elements of a LAG are not being taken down fast enough. > > > > > >I would suggest that a per link BFD solution needs the following > > >properties: > > >- Uses an encapsulation meant to exercise the forwarding path of the > > >traffic > > > it is meant to protect. This is consistent with the original design= of > > > BFD. > > >- SHOULD NOT alter the core BFD state machine if at all possible. E.g.= , > > >MPLS-TP > > > had good reasons to vary it in some circumstances, but was pushed to= be > > > compliant when circumstances did not require the deviation. > > >- If the session bootstrapping mechanism deviates from RFC 5880/5881, i= t > > > MUST NOT cause interoperability issues with BFD sessions on non-LAG > > >links. > > > (I.e. a different UDP destination port.) > > >- SHOULD be port-centric. This means a session should not use a return > > >path > > > that does not exercise the path to be verified for that session. Whi= le > > > this is fine for traditional IP BFD, per link BFD with IP encapsulati= on > > > taking the wrong return path would leave it in question whether it wa= s > > >the > > > forward path or the reverse path that were damaged. > > >- MAY be used as inputs to an aggregated BFD session state between the > two > > > systems. > > > > > >As I mentioned above, I'm very sympathetic with the issues that such > > >requirements would place upon an implementor. There are at least two > > >classes of issues here: > > >- We now need a per-link bootstrapping mechanism different from the > > >existing > > > RFC 5880/5881. > > >- BFD done on a traditional host (routing processor/routing engine/etc.= ) > > > instead of at the line card level becomes messy due to layering issue= s. > > > (I.e. "here's IP destined for this host, please ignore the routing > > > table".) However, I don't think this problem is terribly much worse > > >than > > > IS-IS or VRRP on such hosts. (I agree that it is still gross.) > > > > > >I'd like us to see a bit more discussion around requirements before > > >completely diving into solutions. However, I think the discussion arou= nd > > >the solutions has helped to clarify the issues and the draft has done a > > >good > > >job on driving that discussion. > > > > > >-- Jeff 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 Mon Jan 9 04:14:40 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FCB21F8452 for ; Mon, 9 Jan 2012 04:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.609 X-Spam-Level: X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=0.594, 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 Lxn6yHd7eyeo for ; Mon, 9 Jan 2012 04:14:36 -0800 (PST) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 05ED821F8475 for ; Mon, 9 Jan 2012 04:14:29 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-21.messagelabs.com!1326111267!7583014!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 22195 invoked from network); 9 Jan 2012 12:14:28 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-11.tower-21.messagelabs.com with SMTP; 9 Jan 2012 12:14:28 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-57-4f0adb18de97 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id F7.38.08306.81BDA0F4; Mon, 9 Jan 2012 14:18:32 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 9 Jan 2012 14:14:26 +0200 From: Alexander Vainshtein To: Marc Binderberger , Robert Rennison , Pablo Frank Date: Mon, 9 Jan 2012 14:14:25 +0200 Subject: RE: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Topic: Multicast vs Unicast (was BFD on LAG interfaces) Thread-Index: AczOvhw0aWcdDjSpSOqzwupAC3S4VgAB/qvg Message-ID: References: , <07D139AE-1673-47B4-83B8-C47E69370A33@sniff.de> In-Reply-To: <07D139AE-1673-47B4-83B8-C47E69370A33@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+NgFvrBJsWRmVeSWpSXmKPExsUy+dWnL7oSt7n8DeacM7SYfeU/s8X018fZ LPZNPMVq8fnPNkYHFo+ds+6yeyxZ8pPJo3V1N0sAc1QDo01iXl5+SWJJqkJKanGyrVJAUWZZ YnKlkkJmiq2SoZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbX tbAwtdQ1VLJTUzY0tuYKycgsVkjVzU3MzFHITS0uTkxPVQCKJGxhzpg6+zRTwXLHiltzz7E3 MM437mLk5JAQMJH4eGMTG4QtJnHh3nogm4tDSGAno8TkS1+ZIJzJjBI33y1nBaliE7CV2LT6 LliHiECJxOfLPUwgNrOApkTTic/sXYwcHCwCKhJbrsWChIWByueeec0CUW4ncWH9ByjbSOLU 21/MIDavQKDE9He3WSF2TWKSuPHsOliCU8BG4urWVWA2I9B130+tgdolLnHryXwmiKsFJJbs Oc8MYYtKvHz8jxWiXlTiTvt6Roh6HYkFuz+xQdjaEssWvoZaLChxcuYTFoheSYmDK26wTGAU n4VkxSwk7bOQtM9C0r6AkWUVo2RmTkFJUm66gZFufmmJXmpyZklqTqpecn7uJkZIunmxg/H2 Gc1DjAIcjEo8vBLOXP5CrIllxZW5hxglOZiURHnDrgKF+JLyUyozEosz4otKc1KLDzFKcDAr ifBW9gHleFMSK6tSi/JhUhbAkJ7ILMWdnA9MoXkl8cYGBigcJXHe7uQ3vkIC6cCUl52aWpBa BNMqw8GhJMHbdhNoqmBRanpqRVpmTglCmomDE2QzD9DmFpAa3uKCxNzizHSI/ClGXY4bCxac YxRiycvPS5US550CUiQAUpRRmgc3B5Rh6v////+KURzoZ2HeepAqHmB2gpv0CmgJE9CSB3/Y QZYAcwhcSqqB0bwvKLvwlG7DYu/mZPWrke/tFmxxOit1vyjCKnHJR0vPitKjxxhrXTQF+NXs H5wQObtD/MoSZ/vJtZpzk4wjjv+3OlDfba2mlJB/jrWijPMy84u6mK9tC6tZbPtPadbPF9y0 kHuNiMLOs+cD929heNficPTzktqunUu9f8zP9Y+r1/qzzCVQiaU4I9FQi7moOBEAZjRGegsE AAA= Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 12:14:40 -0000 Marc hi, Lots of thanks for a prompt response. Please see a couple of comments inline below. Regards, Sasha > -----Original Message----- > From: Marc Binderberger [mailto:marc@sniff.de] > Sent: Monday, January 09, 2012 1:02 PM > To: Robert Rennison; Alexander Vainshtein; Pablo Frank > Cc: rtg-bfd@ietf.org > Subject: Re: Multicast vs Unicast (was BFD on LAG interfaces) > > Hello Alexander, > > > Please note also that if micro-BFD sessions are used in conjunction with > > LACP, there is also no need for a new well-known multicast MAC address, > > you can use MAC address of the peer port - learned via LACP - as the > > destination address (and, of course, the local port MAC address as the > > source address). > > true but it binds the solution to LACP as a must-have. While I agree that > LACP is usually used by the customers it also means we have to invent > another solution for the few customers that don't use LACP (for whatever > reason). > > Requesting a well-known MAC is just clean to me for the layer-2 solution. > [[[Sasha]]] I am OK with using a multicast MAC address from the IETF block= if the peer port address is not known. If it is known, using it seems a reasonable choice as well. This is not a bi= g issue anyway. > > Regarding layer-2 vs. layer-3: I agree the first thought may be "BFD in > Ethernet" when looking at the problem. And nothing wrong with it. The > layer-3 topic comes from additional "requirements" from customers that > want to see BFD is related to layer-3 processing. So we try to square a ci= rcle > (or circle a square?). > [[[Sasha]]] I fully agree with you on this point. I have already explained (= in another email) that only the Big Pipe BFD session would exercise the same= forwarding path as true IP traffic. IMHO and FWIW forcing Layer 3 into micro-BFD sessions does not provide any t= angible benefits but definitely adds implementation and, potentially, operat= ional problems - because, at the end of the day, they are NOT Layer 3. Once could argue whether IETF is the right place to define something that is= not Layer 3 - but this is a different story. > Regards, Marc > > > > On 2012-01-09, at 7:05 , Alexander Vainshtein wrote: > > > Rob, Pablo and all, > > > > I concur with Rob: BFD on LAG members using a dedicated Ethertype and > used as an accelerator for LACP detecting the failures of LAG members look= s > like the right thing to do. > > > > Please note also that if micro-BFD sessions are used in conjunction with > LACP, there is also no need for a new well-known multicast MAC address, > you can use MAC address of the peer port - learned via LACP - as the > destination address (and, of course, the local port MAC address as the > source address). > > > > As Jeff has indicated in one of his messages on this thread > (http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01204.html), > the operators tend to use LACP with LAG in any case. As for the exceptions > Jeff has mentioned, IMHO "oldish gear" is not very relevant (it would not > support BFD as well). This leaves "extremely buggy LACP > implementations"... but I do not believe that providing workaround for > someone's bugs is an important objective. > > > > My 2c, > > Sasha > > > > ________________________________________ > > From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of > Robert Rennison [robrennison@gmail.com] > > Sent: Wednesday, January 04, 2012 10:39 PM > > To: Pablo Frank > > Cc: rtg-bfd@ietf.org > > Subject: Re: Multicast vs Unicast (was BFD on LAG interfaces) > > > > Pablo I agree, I am sensing a lot of over-engineering going on in some > > of the discussions re encapsulations, my gut feel going when I saw the > > thread start was, it will quickly settle on using a new Ethertype. > > > > I lost track of or was never really convinced of what concrete reason > > folks would want to be using anything other than an L2 encaps, for > > example the individual links do not have an IP address on them so then > > there were debates about using IP mcast addresses and demuxing on port > > , yeuch. > > > > So on the K.I.S.S principle my vote goes too for trying to getting a > > new Ethertype and do not try to get a spec allowing a multiple of > > encaps as this has the potential to balloon out of all proportion. > > > > Cheers > > > > Rob Rennison > > > > P.s I am also a fan of sticking to having BFD be an adjunct to or an > > accelerator for LACP so have the micro flow or per interface BFD > > sessions provide an early indication to LACP that there is a problem > > with the link. One still potentially needs an overarching slower per > > LAG group BFD session to keep the upper layers happy if they are > > expecting BFD on the IP interface. I say potentially because if the > > interface is now protected by an augmented LACP perhaps the upper > > layers do not need an explicit BFD, that's a more nuanced discussion. > > > > > > On Wed, Jan 4, 2012 at 11:12 AM, Pablo Frank > wrote: > >> I know there's been some arguments made in favour of option 1 that > >> suggest that existing ASICs may be better able to handle > >> IP-encapsulated BFD. Frankly, most vendors are using flexible-enough > >> parsing hardware so I'm not sure this is a very strong argument > >> anymore. So I decided to focus on just looking at it from a pure > >> software IP-stack perspective. > >> > >> It seems that either variant of option 1 requires an implementer to do > >> some pretty ugly hacking to get around existing stack implementations. > >> I tried getting 1a to work using standard Linux socket APIs and ran > >> into all sorts of problems. The fundamental issue is that the member > >> links of a LAG are not normally IP-enabled so trying to bind an IP > >> multicast group membership didn't work. The other issue was trying to > >> force the UDP frames out a particular underlying member link was not > >> possible using the existing socket options for UDP sockets. The only > >> way I got it to work was using AF_PACKET raw sockets and setting up > >> some Berkeley Packet Filters to filter out the frames with the correct > >> L2 multicast MAC address, ethertype, and L3 multicast IP address > >> (since L2 multicast address is not specific enough). But in this > >> case, I'm essentially bypassing the IP stack so I don't get to > >> benefit-from/reuse any of the normal IP stack capabilities (i.e. no IP > >> header validation, checksum checking, etc.). This was really ugly. I > >> didn't even try 1b. > >> > >> Option 2, on the other hand, was trivially easy using AF_PACKET DGRAM > >> sockets. It was very straightforward to bind the TBA ethertype, the > >> TBA multicast MAC, and the interface to use. > >> > >> The fact that option 1 was so convoluted isn't surprising given the > >> obvious layering violations that are taking place here. So unless > >> there are gigantic barriers in place to prevent us from getting a MAC > >> address and ethertype assigned for this kind of low-level BFD, I don't > >> think we should really be seriously considering either variant of > >> option 1. > >> > >> regards, > >> Pablo > >> > >>> 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 > > > > 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 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 jhaas@slice.pfrc.org Mon Jan 9 05:47:03 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715D421F8774 for ; Mon, 9 Jan 2012 05:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.857 X-Spam-Level: X-Spam-Status: No, score=-101.857 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42LtnasrEcx5 for ; Mon, 9 Jan 2012 05:47:03 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E038721F8764 for ; Mon, 9 Jan 2012 05:47:02 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6029A2240C5; Mon, 9 Jan 2012 13:47:02 +0000 (UTC) Date: Mon, 9 Jan 2012 08:47:02 -0500 From: Jeffrey Haas To: Alexander Vainshtein Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Message-ID: <20120109134702.GO7464@slice> References: <20120109022815.GN7464@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 13:47:03 -0000 On Mon, Jan 09, 2012 at 12:29:54PM +0200, Alexander Vainshtein wrote: > One rather obvious problem with the IP-based encapsulation (multicast or unicast) is IMHO that it is a clear layer violation. > Pablo has already commented on implementation problems with this approach in his message ( http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01207.html) and their origin in the said layer violation. As I mentioned in my own post, I agree that it's a gross thing to do if you're generating packets on a central routing engine rather than on a line card. But it certainly won't be the first time routers bang the bits on the wire directly rather than running things through the stack. After working through the requirements, if we end up with a solution that doesn't require such a thing, that's a win. > I also have certain doubts interpreting the statements like " BFD provides its functionality by exercising the forwarding path" in Jeffrey's message (http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01212.html ). > The forwarding path for IP traffic sent treats LAG as the interface (or, in the 802.1AX terms, IP is a client of the LAG MAC - see Figure 5.3 in the IEEE 802.1AX-2008). This means that: > - Source MAC address of IP packets transmitted via LAGF is MAC address of the LAG (does not depend on the specific LAG member over which it is actually transmitted) > - Destination MAC address of the unicast IP packet is MAC address of the peer LAG (discovered via ARP for IPv4 or ND for IPv6) > - IP layer does not exercise any kind of explicit control over selection of the LAG member over which the packet. Instead selection is done by the LAG distributor. In fact, with most distributors, all BFD packets would be transmitted via a single LAG member link because they would be identified as belonging to the same flow. And BFD that exercises this forwarding path is what draft-mmm calls the "Big Pipe BFD session". (BTW, Big Pipe BFD that distribute BFD packets over all LAG members actually exercise a different forwarding path). This is a fair observation. It is entirely possible that an implementation may only process IP traffic to the LAG MAC rather than to a LAG member MAC. Thinking about a possible implementation rather than discussing requirements, my expectation would be that the BFD IP packets are generated on the LAG member and destined to the LAG MAC. If the LAG BFD implementation is not distributed to the individual interfaces, the only way to determine that a given packet was coming in a given interface would be a priori knowledge via the discriminators. While it's possible a given routing engine may have knowledge of what individual port of a LAG the packet came in, it's just as likely that you'd get the LAG aggregate port interface index back. I'll ponder some text for this, but for the moment I'd prefer to focus on requirements for now. -- Jeff From jhaas@slice.pfrc.org Mon Jan 9 06:03:32 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4456721F8684 for ; Mon, 9 Jan 2012 06:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1cSFhkljRbq for ; Mon, 9 Jan 2012 06:03:31 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BFD8A21F864B for ; Mon, 9 Jan 2012 06:03:31 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8411F224064; Mon, 9 Jan 2012 14:03:31 +0000 (UTC) Date: Mon, 9 Jan 2012 09:03:31 -0500 From: Jeffrey Haas To: Tom Sanders Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Message-ID: <20120109140331.GQ7464@slice> References: <20120109022815.GN7464@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 14:03:32 -0000 Tom, On Mon, Jan 09, 2012 at 02:11:05PM +0530, Tom Sanders wrote: > I would not want to restrict ourselves by merely saying "forwarding IP > traffic". I dont see why a solution to preclude the possibility of > supporting VPLS or VPWS in which case one could have a LAG thats used > for forwarding L2 frames. > > The idea is to get rid of LACP. The idea is to use BFD for fast > detection since folks know and understand BFD. We could have achieved > the same using ethernet OAM but folks did not want to do that. I believe I strongly disagree with the idea we're trying to get rid of LACP. However, moving this back to requirements it can be observed we could accomplish the goal making sure IP traffic is delivered across the link either by: 1. Testing the IP forwarding ability of a given link. 2. Testing the frame forwarding ability of a given link. 2 seems to be closer to what you're looking for. BFD over Ethernet in such a case would work here. It could then inform protocols such as LACP so it could converge faster. One of the reasons I think 1 is a better requirement is that when we're talking about aggregate links (regardless of link layer type), the operation we're really concerned about is whether we can forward our higher layer traffic over it. This not only involves ensuring that the logical aggregate link is presented to the implementation but whether the implementation can use it for that purpose. Put a slightly different way, just because you have a LAG doesn't mean that your forwarding is working over a component. I suspect any number of operators could pick their favorite bug where this has happened. Please note that I'm not suggesting we try to verify load balancing for LAG members. Doing so is wildly out of scope for BFD. > AS i mentioned earlier, I think we'll be very myopic if we restrict > ourselves to IP unicast traffic. What prevents us from using that link > for multicast traffic or L2 traffic? The goal is to exercise the forwarding path for the service protected by BFD. If your traffic is IPv4 unicast, your BFD session should be as well. If you traffic is MPLS, ditto. While I'm unclear how many implementations actually do this, it is arguable that if you're protecting a given CoS for IPv4 unicast, you should have a distinct IPv4 unicast BFD session using that CoS. This is because queueing and forwarding hardware may forward differently and you want to know if you get bi-directional forwarding for that CoS within your session's tolerance. However, I suspect most vendors simply choose to go with fate sharing of the address family; it minimizes the sessions you need. Similarly, when trying to provide feedback for LACP, one design choice could be to use the fate of IPv4 forwarding on a component to decide a LAG member is up or down based on fate sharing. A somewhat similar choice is faced when protecting IS-IS sessions on a link: IS-IS is not IP traffic. -- Jeff From Alexander.Vainshtein@ecitele.com Mon Jan 9 07:06:13 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F141E11E8072 for ; Mon, 9 Jan 2012 07:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.946, 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 21fO45JXANeH for ; Mon, 9 Jan 2012 07:06:09 -0800 (PST) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 92E2811E8071 for ; Mon, 9 Jan 2012 07:06:08 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1326121564!10225189!2 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 8744 invoked from network); 9 Jan 2012 15:06:06 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-3.tower-216.messagelabs.com with SMTP; 9 Jan 2012 15:06:06 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-7a-4f0b03528822 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 84.8C.08306.2530B0F4; Mon, 9 Jan 2012 17:10:11 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 9 Jan 2012 17:06:05 +0200 From: Alexander Vainshtein To: Jeffrey Haas Date: Mon, 9 Jan 2012 17:06:03 +0200 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczO126eVvQaG98GSI2SnkPiONJLSgABG1OQ Message-ID: References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> In-Reply-To: <20120109140331.GQ7464@slice> 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: H4sIAAAAAAAAA2VTa0gUURjtzqy74+rEuD72ugVOk0RqK9pzzbYH9cOiULN+lKBdd2+7Q7sz y84YGkRGRmRkD6loodVArCwSyqwoiN0kUkKFsLf2sih7ICq9kLYZp8xofp2555zvfPfyfRRp GtZbKF6QsV9AHk5v1NUNDo9ai8iY/KzHQcZ2K/QpyjYy1gZsvcPniOVk3vVAnyGvsfE7kXf/ 4JWoAnJzFViCBEGUkYxZJ5Ycdq7Az29HjkqO5Z12LptjfR7kwF4syHYO+XxYcHJLjex/3xJF xgssFhyikxdcdm51Ub7VZluQY83mls6amT0v17jBzUsstnoR72G9WJKQC7PKyZZW0n37fSPh e5tZETq6h6wCkdQaEE1BZj68W39Ip+Ek2NPfoq8BRsrEXAdw7MNRoBImpg7AwfvrVaxn7PDS +T69ihOYGbA+sn8ck0whDB3sGS+kY1Lhw/bqcRzPIPi2rQ5o+jJYezmg0/BcGDpzz6BiWvH2 jn4zaFlBAg70r1BxNJMOQ7Ut4+dAae5r5wVCyzLDJwP1hNY0AxtvdpMaToTvX/+M0vSJ8Nm+ FqDp58CGG8O/+8yATac/kFpuHOw4OfD78skwdPaR7jAwByZFBCbZA5PsgUn2BqBrBsm8xyeX eV1Zc61iuZyJHbyMPTjTIXovAW1i3l0DT++lhQFDAS6WhiuN+aYotF2q9IZBMkVwifQmEJNv mlomOivdSHKX+ss9WAoDSJFcAh2conC0E1XuwH7xD2VTXvoIaYlxiMpsCnLpvKysf344M33A 8XGdiXEpg7cNYx/2/7FOpygO0vVqYpwfu3DFVt4j/6UJKlpNjlWST6gaWvIhr8S7NL4TWKmH u091AZNOEAVsMdNtqohRRe5yYaKOuiq7IpHIIDArd46nj6uqWGWRJioNKiGEEvJizKCGKAsy QVmqQLx4fC+bUnVxdqA1esWV4p6XtbR70eJ1byoKLUzKsZ27FiblGSJSWnBffJBrQi+T4oRv bM+a4o3PybWdrpL21K7CmqsvMqY6E8zLPO0PUGnO0OWtI2Eyt/tidW+4aeWj0Y/tn5uHUq6W 3PmxZtnJopwaf1xHoKH31TTY+mXvnIpVnE5yo+x00i+hX5JW03oFBAAA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:06:13 -0000 Jeff, I may be completely wrong here, but it seems that you are more worried about= buggy LAG implementations (like in "you have a LAG doesn't mean that your f= orwarding is working over a component") than about "true" link failures (fib= er cut etc.). I am not sure BFD over LAG members is the right tool to help with buggy LAG= implementations. In fact, I strongly suspect that it would rather add its o= wn bugs on top of the already existing ones... My understanding of the original problem that BFD over LAG members tries to= solve is like following 1. We are dealing with a LAG between a pair of, say adjacent routers that is= comprised of links that do not support detection of link failure at the phy= sical layer (e.g., loss of optical power) - if they were, we would not ne= ed BFD to do the same. 2. We want to detect failure of individual LAG members much faster than coul= d be done by using standard LACP. 3. Fast detection of failure of the LAG member would result in: - Immediate bi-directional removal of this link from distribution in order= to avoid back-holing of traffic. This may be followed by inclusion of some "spare links" into distribution= (if these links exist and are alive) - Bringing down the entire LAG if the "Insufficient active links" condition= has been detected. Bringing LAG down affects all its MAC clients in the usual way. 4. 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. 5. We are looking for a solution that is: - Based on the base BFD spec (RFC 5880) - among other reasons because of it= s operational simplicity - Operates normally in the presence of LACP and, optionally, may operate no= rmally if LACP is not used. This is very close to what I've written 3 weeks ago in my message to the lis= t - see http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01151.html. There is an implicit "implementation sanity" assumption here, e.g., that if= the link has been found to be bi-directionally collecting and distributing,= any packet LAG receives from its MAC client and decides to transmit via suc= h a link would be received by the peer MAC client at the other end. Could we take this problem statement as the starting point? If not, what, in= your opinion, is the problem we try to address? Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Monday, January 09, 2012 4:04 PM > To: Tom Sanders > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was > BFD on LAG interfaces)) > > Tom, > > On Mon, Jan 09, 2012 at 02:11:05PM +0530, Tom Sanders wrote: > > I would not want to restrict ourselves by merely saying "forwarding IP > > traffic". I dont see why a solution to preclude the possibility of > > supporting VPLS or VPWS in which case one could have a LAG thats used > > for forwarding L2 frames. > > > > The idea is to get rid of LACP. The idea is to use BFD for fast > > detection since folks know and understand BFD. We could have achieved > > the same using ethernet OAM but folks did not want to do that. > > I believe I strongly disagree with the idea we're trying to get rid of LAC= P. > However, moving this back to requirements it can be observed we could > accomplish the goal making sure IP traffic is delivered across the link > either by: > 1. Testing the IP forwarding ability of a given link. > 2. Testing the frame forwarding ability of a given link. > > 2 seems to be closer to what you're looking for. BFD over Ethernet in suc= h > a case would work here. It could then inform protocols such as LACP so it > could converge faster. > > One of the reasons I think 1 is a better requirement is that when we're > talking about aggregate links (regardless of link layer type), the operati= on > we're really concerned about is whether we can forward our higher layer > traffic over it. This not only involves ensuring that the logical aggrega= te > link is presented to the implementation but whether the implementation > can > use it for that purpose. > > Put a slightly different way, just because you have a LAG doesn't mean tha= t > your forwarding is working over a component. I suspect any number of > operators could pick their favorite bug where this has happened. > > Please note that I'm not suggesting we try to verify load balancing for LA= G > members. Doing so is wildly out of scope for BFD. > > > AS i mentioned earlier, I think we'll be very myopic if we restrict > > ourselves to IP unicast traffic. What prevents us from using that link > > for multicast traffic or L2 traffic? > > The goal is to exercise the forwarding path for the service protected by > BFD. If your traffic is IPv4 unicast, your BFD session should be as well. > If you traffic is MPLS, ditto. > > While I'm unclear how many implementations actually do this, it is arguabl= e > that if you're protecting a given CoS for IPv4 unicast, you should have a > distinct IPv4 unicast BFD session using that CoS. This is because queuein= g > and forwarding hardware may forward differently and you want to know if > you > get bi-directional forwarding for that CoS within your session's tolerance= . > However, I suspect most vendors simply choose to go with fate sharing of > the > address family; it minimizes the sessions you need. > > Similarly, when trying to provide feedback for LACP, one design choice > could > be to use the fate of IPv4 forwarding on a component to decide a LAG > member > is up or down based on fate sharing. A somewhat similar choice is faced > when protecting IS-IS sessions on a link: IS-IS is not IP traffic. > > -- Jeff 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 pabloisnot@gmail.com Mon Jan 9 08:30:36 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D764811E8072 for ; Mon, 9 Jan 2012 08:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.671 X-Spam-Level: X-Spam-Status: No, score=-2.671 tagged_above=-999 required=5 tests=[AWL=0.927, 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 oVATSzGZrV3T for ; Mon, 9 Jan 2012 08:30:35 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8FA21F8427 for ; Mon, 9 Jan 2012 08:30:35 -0800 (PST) Received: by obcuz6 with SMTP id uz6so4827036obc.31 for ; Mon, 09 Jan 2012 08:30:35 -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=KAkkqucjd1TbhixQnMAL0Ig8MD20KrWEDBmbW/oWTBg=; b=q0mxWtnjDSTINdDzrhxHpcHrHBMfDZZ071g5yDjza7agfPKcm2RMPpk50//t/80I2l 1KwclPkgKmFuh5rThldlgL0WZit4lbWyx0LiZhOJbZ3xYxoEZYYqHPjUlsy7719cqs57 tDoCABl37MqUadSRcVEQAqISar4WPf0709/1k= MIME-Version: 1.0 Received: by 10.182.117.8 with SMTP id ka8mr15141810obb.73.1326126634962; Mon, 09 Jan 2012 08:30:34 -0800 (PST) Received: by 10.182.159.6 with HTTP; Mon, 9 Jan 2012 08:30:34 -0800 (PST) In-Reply-To: <20120109140331.GQ7464@slice> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> Date: Mon, 9 Jan 2012 11:30:34 -0500 Message-ID: Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) From: Pablo Frank To: Jeffrey Haas Content-Type: multipart/alternative; boundary=f46d04478603010e1504b61aebae Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 16:30:37 -0000 --f46d04478603010e1504b61aebae Content-Type: text/plain; charset=ISO-8859-1 Jeff, I think you ask a very good fundamental question at the beginning of this thread. Essentially, are we trying to monitor L2 continuity or L3 continuity across the LAG? If the goal is to monitor L2 connectivity, then clearly the direct L2 encapsulation of BFD achieves that and is fairly trivial to implement. Of course, the IEEE could do this just as easily with Ethernet OAM and I've heard rumours that they intend to address this issue soon. Is there a liaison with the IEEE who can confirm this? However, as has been pointed out, L2 connectivity does not necessarily mean that you can forward L3 successfully. If the goal is to monitor the L3 forwarding path, then I don't think the proposed solutions in the draft do that either. Injecting IP unicast or multicast frames directly into the member links of a LAG does not necessarily test the L3 datapath because normal packets would be subject to the LAG distribution algorithm. And that's kinda the rub. If I want to ensure that my L3 frames will cross a LAG correctly, I need to have visibility into the LAG distributor and source frames that will predictably test the individual legs of the LAG. For IP, this means varying the IP src/dst and UDP src/dst (how would you do this with the normal IP BFD encap?). For MPLS sections, I suppose one could vary the entropy label. Of course, all this assumes that the behaviour of the distributor is known and predictable. I'm just not sure how you can write a standard around this. But there's an additional issue with running BFD at the L3 level instead of L2. If that's what you choose to do then I don't think that a L3 BFD session has any business trying to influence the state of LACP that's running down at the link layer. I think if you choose to implement a "LAG-aware" L3 BFD session, then all you should be doing with the state information is influencing your L3 operational state (and taking corrective action at L3 such as protection switching, re-routing, etc.). It seems to me that we can't have our cake and eat it too. There isn't a single solution that will solve both the L2 and L3 problem domains in one shot, nor should we try to achieve that. It seems to me that the L2 solution should aim to solve the LACP slow convergence problem and not attempt to verify L3 connectivity. The IETF could try solving this with a L2 BFD/LAG link approach but an IEEE solution is equally valid and they likely *should* own this problem. There might be a room for a L3 "LAG-aware" solution but the goal here is verifying L3 operational state and it should certainly NOT be trying to influence the state of the L2 LAG members. In my mind, these two approaches could easily coexist and integrates well into a layered protection model. regards, Pablo On Mon, Jan 9, 2012 at 9:03 AM, Jeffrey Haas wrote: > Tom, > > On Mon, Jan 09, 2012 at 02:11:05PM +0530, Tom Sanders wrote: > > I would not want to restrict ourselves by merely saying "forwarding IP > > traffic". I dont see why a solution to preclude the possibility of > > supporting VPLS or VPWS in which case one could have a LAG thats used > > for forwarding L2 frames. > > > > The idea is to get rid of LACP. The idea is to use BFD for fast > > detection since folks know and understand BFD. We could have achieved > > the same using ethernet OAM but folks did not want to do that. > > I believe I strongly disagree with the idea we're trying to get rid of > LACP. > However, moving this back to requirements it can be observed we could > accomplish the goal making sure IP traffic is delivered across the link > either by: > 1. Testing the IP forwarding ability of a given link. > 2. Testing the frame forwarding ability of a given link. > > 2 seems to be closer to what you're looking for. BFD over Ethernet in such > a case would work here. It could then inform protocols such as LACP so it > could converge faster. > > One of the reasons I think 1 is a better requirement is that when we're > talking about aggregate links (regardless of link layer type), the > operation > we're really concerned about is whether we can forward our higher layer > traffic over it. This not only involves ensuring that the logical > aggregate > link is presented to the implementation but whether the implementation can > use it for that purpose. > > Put a slightly different way, just because you have a LAG doesn't mean that > your forwarding is working over a component. I suspect any number of > operators could pick their favorite bug where this has happened. > > Please note that I'm not suggesting we try to verify load balancing for LAG > members. Doing so is wildly out of scope for BFD. > > > AS i mentioned earlier, I think we'll be very myopic if we restrict > > ourselves to IP unicast traffic. What prevents us from using that link > > for multicast traffic or L2 traffic? > > The goal is to exercise the forwarding path for the service protected by > BFD. If your traffic is IPv4 unicast, your BFD session should be as well. > If you traffic is MPLS, ditto. > > While I'm unclear how many implementations actually do this, it is arguable > that if you're protecting a given CoS for IPv4 unicast, you should have a > distinct IPv4 unicast BFD session using that CoS. This is because queueing > and forwarding hardware may forward differently and you want to know if you > get bi-directional forwarding for that CoS within your session's tolerance. > However, I suspect most vendors simply choose to go with fate sharing of > the > address family; it minimizes the sessions you need. > > Similarly, when trying to provide feedback for LACP, one design choice > could > be to use the fate of IPv4 forwarding on a component to decide a LAG member > is up or down based on fate sharing. A somewhat similar choice is faced > when protecting IS-IS sessions on a link: IS-IS is not IP traffic. > > -- Jeff > --f46d04478603010e1504b61aebae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jeff,

I think you ask a very good fundamental ques= tion at the beginning of this thread. =A0Essentially, are we trying to moni= tor L2 continuity or L3 continuity across the LAG? =A0

I= f the goal is to monitor L2 connectivity, then clearly the direct L2 encaps= ulation of BFD achieves that and is fairly trivial to implement. =A0Of cour= se, the IEEE could do this just as easily with Ethernet OAM and I've he= ard rumours that they intend to address this issue soon. =A0Is there a=A0li= aison=A0with the IEEE who can confirm this? =A0However, as has been pointed= out, L2 connectivity does not necessarily mean that you can forward L3 suc= cessfully.

If the goal is to monitor the L3 forwarding path, then = I don't think the proposed solutions in the draft do that either. =A0In= jecting IP unicast or multicast frames directly into the member links of a = LAG does not necessarily test the L3 datapath because normal packets would = be subject to the LAG distribution algorithm. =A0And that's kinda the r= ub. =A0If I want to ensure that my L3 frames will cross a LAG correctly, I = need to have visibility into the LAG distributor and source frames that wil= l predictably test the individual legs of the LAG. =A0For IP, this means va= rying the IP src/dst and UDP src/dst (how would you do this with the normal= IP BFD encap?). =A0For MPLS sections, I suppose one could vary the entropy= label. =A0Of course, all this assumes that the behaviour of the distributo= r is known and predictable. =A0I'm just not sure how you can write a st= andard around this.

But there's an additional issue with running BFD at= the L3 level instead of L2. =A0If that's what you choose to do then I = don't think that a L3 BFD session has any business trying to influence = the state of LACP that's running down at the link layer. =A0I think if = you choose to implement a "LAG-aware" L3 BFD session, then all yo= u should be doing with the state information is=A0influencing your L3 opera= tional state (and taking corrective action at L3 such as protection switchi= ng, re-routing, etc.). =A0=A0

It seems to me that we can't have our cake and eat = it too. =A0There isn't a single solution that will solve both the L2 an= d L3 problem domains in one shot, nor should we try to achieve that. =A0It = seems to me that the L2 solution should aim to solve the LACP slow converge= nce problem and not attempt to verify L3 connectivity. =A0The IETF could tr= y solving this with a L2 BFD/LAG link approach but an IEEE solution is equa= lly valid and they likely *should* own this problem. =A0There might be a ro= om for a L3 "LAG-aware" solution but the goal here is verifying L= 3 operational state and it should certainly NOT be trying to influence the = state of the L2 LAG members. =A0In my mind, these two approaches could easi= ly coexist and integrates well into a layered protection model.

regards,
Pablo

On Mon, Jan 9, 2012 at 9:03 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Tom,

On Mon, Jan 09, 2012 at 02:11:05PM +0530, Tom Sanders wrote:
> I would not want to restrict ourselves by merely saying "forwardi= ng IP
> traffic". I dont see why a solution to preclude the possibility o= f
> supporting VPLS or VPWS in which case one could have a LAG thats used<= br> > for forwarding L2 frames.
>
> The idea is to get rid of LACP. The idea is to use BFD for fast
> detection since folks know and understand BFD. We could have achieved<= br> > the same using ethernet OAM but folks did not want to do that.

I believe I strongly disagree with the idea we're trying to get r= id of LACP.
However, moving this back to requirements it can be observed we could
accomplish the goal making sure IP traffic is delivered across the link
either by:
1. Testing the IP forwarding ability of a given link.
2. Testing the frame forwarding ability of a given link.

2 seems to be closer to what you're looking for. =A0BFD over Ethernet i= n such
a case would work here. =A0It could then inform protocols such as LACP so i= t
could converge faster.

One of the reasons I think 1 is a better requirement is that when we're=
talking about aggregate links (regardless of link layer type), the operatio= n
we're really concerned about is whether we can forward our higher layer=
traffic over it. =A0This not only involves ensuring that the logical aggreg= ate
link is presented to the implementation but whether the implementation can<= br> use it for that purpose.

Put a slightly different way, just because you have a LAG doesn't mean = that
your forwarding is working over a component. =A0I suspect any number of
operators could pick their favorite bug where this has happened.

Please note that I'm not suggesting we try to verify load balancing for= LAG
members. =A0Doing so is wildly out of scope for BFD.

> AS i mentioned earlier, I think we'll be very myopic if we restric= t
> ourselves to IP unicast traffic. What prevents us from using that link=
> for multicast traffic or L2 traffic?

The goal is to exercise the forwarding path for the service protected= by
BFD. =A0If your traffic is IPv4 unicast, your BFD session should be as well= .
If you traffic is MPLS, ditto.

While I'm unclear how many implementations actually do this, it is argu= able
that if you're protecting a given CoS for IPv4 unicast, you should have= a
distinct IPv4 unicast BFD session using that CoS. =A0This is because queuei= ng
and forwarding hardware may forward differently and you want to know if you=
get bi-directional forwarding for that CoS within your session's tolera= nce.
However, I suspect most vendors simply choose to go with fate sharing of th= e
address family; it minimizes the sessions you need.

Similarly, when trying to provide feedback for LACP, one design choice coul= d
be to use the fate of IPv4 forwarding on a component to decide a LAG member=
is up or down based on fate sharing. =A0A somewhat similar choice is faced<= br> when protecting IS-IS sessions on a link: IS-IS is not IP traffic.

-- Jeff

--f46d04478603010e1504b61aebae-- From marc@sniff.de Mon Jan 9 08:48:33 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D8821F85BE for ; Mon, 9 Jan 2012 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 rKUtl6e0ANFn for ; Mon, 9 Jan 2012 08:48:29 -0800 (PST) Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2521F8593 for ; Mon, 9 Jan 2012 08:48:28 -0800 (PST) Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 6BE452AA11; Mon, 9 Jan 2012 16:48:26 +0000 (GMT) Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was 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, 9 Jan 2012 17:48:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <885C6A9D-D35D-4388-9EE7-2A58F2F06D3E@sniff.de> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> To: Alexander Vainshtein 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: Mon, 09 Jan 2012 16:48:33 -0000 Hello Alexander, > Jeff, >=20 > I may be completely wrong here, but it seems that you are more worried = about buggy LAG implementations (like in "you have a LAG doesn't mean = that your forwarding is working over a component") than about "true" = link failures (fiber cut etc.). not sure this is about buggy LAG implementations. More about layer-3 = issues.=20 The following scenario: you have a LAG, 2 links across two I/O cards. = The BBP session may use - by accident - only link1 on I/O card 1 while = the layer-3 hw on I/O card 2 is broken. Assuming you have many IP flows = across the LAG you probably blackhole 50% of your traffic. So BBP alone may not detect the situation and layer-3 based micro = sessions would be required. At least this is how I was reading Jeff's email. Regards, Marc >=20 > I am not sure BFD over LAG members is the right tool to help with = buggy LAG implementations. In fact, I strongly suspect that it would = rather add its own bugs on top of the already existing ones... >=20 > My understanding of the original problem that BFD over LAG members = tries to solve is like following >=20 > 1. We are dealing with a LAG between a pair of, say adjacent routers = that is comprised of links that do not support detection of link failure = at the physical layer (e.g., loss of optical power) - if they were, = we would not need BFD to do the same. > 2. We want to detect failure of individual LAG members much faster = than could be done by using standard LACP. > 3. Fast detection of failure of the LAG member would result in: > - Immediate bi-directional removal of this link from = distribution in order to avoid back-holing of traffic. > This may be followed by inclusion of some "spare links" into = distribution (if these links exist and are alive) > - Bringing down the entire LAG if the "Insufficient active = links" condition has been detected. > Bringing LAG down affects all its MAC clients in the usual = way. > 4. 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. > 5. We are looking for a solution that is: > - Based on the base BFD spec (RFC 5880) - among other reasons = because of its operational simplicity > - Operates normally in the presence of LACP and, optionally, may = operate normally if LACP is not used. >=20 > This is very close to what I've written 3 weeks ago in my message to = the list - see = http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01151.html. > There is an implicit "implementation sanity" assumption here, e.g., = that if the link has been found to be bi-directionally collecting and = distributing, any packet LAG receives from its MAC client and decides to = transmit via such a link would be received by the peer MAC client at the = other end. >=20 > Could we take this problem statement as the starting point? If not, = what, in your opinion, is the problem we try to address? >=20 > Regards, > Sasha >=20 >=20 >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Jeffrey Haas >> Sent: Monday, January 09, 2012 4:04 PM >> To: Tom Sanders >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast = (was >> BFD on LAG interfaces)) >>=20 >> Tom, >>=20 >> On Mon, Jan 09, 2012 at 02:11:05PM +0530, Tom Sanders wrote: >>> I would not want to restrict ourselves by merely saying "forwarding = IP >>> traffic". I dont see why a solution to preclude the possibility of >>> supporting VPLS or VPWS in which case one could have a LAG thats = used >>> for forwarding L2 frames. >>>=20 >>> The idea is to get rid of LACP. The idea is to use BFD for fast >>> detection since folks know and understand BFD. We could have = achieved >>> the same using ethernet OAM but folks did not want to do that. >>=20 >> I believe I strongly disagree with the idea we're trying to get rid = of LACP. >> However, moving this back to requirements it can be observed we could >> accomplish the goal making sure IP traffic is delivered across the = link >> either by: >> 1. Testing the IP forwarding ability of a given link. >> 2. Testing the frame forwarding ability of a given link. >>=20 >> 2 seems to be closer to what you're looking for. BFD over Ethernet = in such >> a case would work here. It could then inform protocols such as LACP = so it >> could converge faster. >>=20 >> One of the reasons I think 1 is a better requirement is that when = we're >> talking about aggregate links (regardless of link layer type), the = operation >> we're really concerned about is whether we can forward our higher = layer >> traffic over it. This not only involves ensuring that the logical = aggregate >> link is presented to the implementation but whether the = implementation >> can >> use it for that purpose. >>=20 >> Put a slightly different way, just because you have a LAG doesn't = mean that >> your forwarding is working over a component. I suspect any number of >> operators could pick their favorite bug where this has happened. >>=20 >> Please note that I'm not suggesting we try to verify load balancing = for LAG >> members. Doing so is wildly out of scope for BFD. >>=20 >>> AS i mentioned earlier, I think we'll be very myopic if we restrict >>> ourselves to IP unicast traffic. What prevents us from using that = link >>> for multicast traffic or L2 traffic? >>=20 >> The goal is to exercise the forwarding path for the service protected = by >> BFD. If your traffic is IPv4 unicast, your BFD session should be as = well. >> If you traffic is MPLS, ditto. >>=20 >> While I'm unclear how many implementations actually do this, it is = arguable >> that if you're protecting a given CoS for IPv4 unicast, you should = have a >> distinct IPv4 unicast BFD session using that CoS. This is because = queueing >> and forwarding hardware may forward differently and you want to know = if >> you >> get bi-directional forwarding for that CoS within your session's = tolerance. >> However, I suspect most vendors simply choose to go with fate sharing = of >> the >> address family; it minimizes the sessions you need. >>=20 >> Similarly, when trying to provide feedback for LACP, one design = choice >> could >> be to use the fate of IPv4 forwarding on a component to decide a LAG >> member >> is up or down based on fate sharing. A somewhat similar choice is = faced >> when protecting IS-IS sessions on a link: IS-IS is not IP traffic. >>=20 >> -- Jeff >=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 Alexander.Vainshtein@ecitele.com Mon Jan 9 10:00:31 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2815C21F8700 for ; Mon, 9 Jan 2012 10:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=-0.887, 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 j-7c5jIeVMb8 for ; Mon, 9 Jan 2012 10:00:27 -0800 (PST) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id A155621F86DA for ; Mon, 9 Jan 2012 10:00:20 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-182.messagelabs.com!1326132015!10170612!3 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 16190 invoked from network); 9 Jan 2012 18:00:18 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-9.tower-182.messagelabs.com with SMTP; 9 Jan 2012 18:00:18 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-61-4f0b2c20b05a Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 56.1F.08306.02C2B0F4; Mon, 9 Jan 2012 20:04:16 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 9 Jan 2012 20:00:10 +0200 From: Alexander Vainshtein To: Marc Binderberger Date: Mon, 9 Jan 2012 19:59:46 +0200 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczO7oUNO4XWa4WKSF6wonRnWiDXTgACGOy1 Message-ID: References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> , <885C6A9D-D35D-4388-9EE7-2A58F2F06D3E@sniff.de> In-Reply-To: <885C6A9D-D35D-4388-9EE7-2A58F2F06D3E@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+NgFvrFJsWRmVeSWpSXmKPExsUy+dWnL7oKOtz+BqtmaVvsP/iW1WL2lf/M Fp//bGN0YPZYsuQnk8fl3q2sHq2ru1kCmKMaGG0S8/LySxJLUhVSUouTbZUCijLLEpMrlRQy U2yVDJUUCnISk1NzU/NKbJUSCwpS81KU7LgUMIANUFlmnkJqXnJ+SmZeuq2SZ7C/roWFqaWu oZKdmrKhsTVXSEZmsUKqbm5iZo5CbmpxcWJ6qgJQJGELc8a0E3vZC+45Vexf84mpgfG0SRcj J4eEgInElvVzmSFsMYkL99azdTFycQgJ7GaUOPq8hQnCmcoocWzJc3aQKjYBW4lNq++ygdgi AqoSd18fYgSxmQU8JPq27gaLswioSFy8tQ3MFhZIlLj3sJERoj5JouHUD1YI20hiweSjYDav QKDEnPurmSGWTWOWeHHtGBNIglPARuLin+UsIDYj0HnfT61hglgmLnHryXwmiLMFJJbsOQ/1 gqjEy8f/WCHqRSXutK+HOk5HYsHuT2wQtrbEsoWvmSEWC0qcnPmEBaJXUuLgihssExjFZyFZ MQtJ+ywk7bOQtC9gZFnFKJmZU1CSlJtuYKSbX1qil5qcWZKak6qXnJ+7iRGSZl7sYLx9RvMQ owAHoxIPr4Qzl78Qa2JZcWXuIUZJDiYlUV5hDW5/Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK8 8xiAcrwpiZVVqUX5MCkLYFBPZJbiTs4Hps68knhjAwMUjpI4b3fyG18hgXRg0stOTS1ILYJp leHgUJLgzdQCmipYlJqeWpGWmVOCkGbi4ATZzAO0OQWkhre4IDG3ODMdIn+K0ZjjeuPcc4wc NxYsOMcoxJKXn5cqJc5rD1IqAFKaUZoHNw2UZer/////ilEc6HNh3jiQKh5ghoKb9wpoFRPQ KlFRsFXAjAKXkmpgXO89Tee16IbUtRdqby6f5JHIx3i6ZsPCHiuuBcl3Ul3rm/Qm1f2e94bb q4Lt8XHpny7pe+ZGil2IWHT7eNf0F1M/SOeuL7cIF/B/W3JKQaiMPbNI/Jb0nt4Nh8ROW11Z ++VNcxef7ft3NXP3L40LTX7bfKrlXN/ijffOJ57MuqRz1mfFfGbjT0osxRmJhlrMRcWJAPeT fPoNBAAA Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:00:31 -0000 Marc hi, Lots of thanks for a prompt response and an excellent example of what could= go wrong ("layer-3 hw on I/O card 2 is broken"). I can take it a bit further: Please consider a 1-hop IPv4/IPv6 BFD implement= ation (RFC 5881) where received BFD packets are identified early in the forw= arding path and sent to the appropriate HW or SW entity, while "regular" IPv= 4 packets (with destination addresses not owned by the receiving router) are= sent for the longest prefix match look-up in a corrupted table ("broken HW"= or "SW bug") and, as a consequence, are black-holed. There is even no need= in LAG... Please note that since IP and MPLS lookups are in different tables, IP traff= ic with the same destination addresses but encapsulated in MPLS could be per= fectly healthy... In other words, it is important to agree in advance which kind of failures y= ou want to detect. To my taste, 1-hop BFD reliably covers the media between the pair of adjace= nt routers (be it a physical link, a LAN or something else). Once your BFD p= ackets have been successfully received by the router, the actual coverage is= implementation-specific. Did I miss something? Regards, Sasha ________________________________________ From: Marc Binderberger [marc@sniff.de] Sent: Monday, January 09, 2012 6:48 PM To: Alexander Vainshtein Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD= on LAG interfaces)) Hello Alexander, > Jeff, > > I may be completely wrong here, but it seems that you are more worried abo= ut buggy LAG implementations (like in "you have a LAG doesn't mean that your= forwarding is working over a component") than about "true" link failures (f= iber cut etc.). not sure this is about buggy LAG implementations. More about layer-3 issues. The following scenario: you have a LAG, 2 links across two I/O cards. The BB= P session may use - by accident - only link1 on I/O card 1 while the layer-3= hw on I/O card 2 is broken. Assuming you have many IP flows across the LAG= you probably blackhole 50% of your traffic. So BBP alone may not detect the situation and layer-3 based micro sessions w= ould be required. At least this is how I was reading Jeff's email. Regards, Marc > > I am not sure BFD over LAG members is the right tool to help with buggy LA= G implementations. In fact, I strongly suspect that it would rather add its= own bugs on top of the already existing ones... > > My understanding of the original problem that BFD over LAG members tries t= o solve is like following > > 1. We are dealing with a LAG between a pair of, say adjacent routers that= is comprised of links that do not support detection of link failure at the= physical layer (e.g., loss of optical power) - if they were, we would no= t need BFD to do the same. > 2. We want to detect failure of individual LAG members much faster than co= uld be done by using standard LACP. > 3. Fast detection of failure of the LAG member would result in: > - Immediate bi-directional removal of this link from distribution in= order to avoid back-holing of traffic. > This may be followed by inclusion of some "spare links" into distr= ibution (if these links exist and are alive) > - Bringing down the entire LAG if the "Insufficient active links" co= ndition has been detected. > Bringing LAG down affects all its MAC clients in the usual way. > 4. The situation when LAG goes down due to insufficient number of active l= inks must be reversible, i.e., the LAG must be able to go UP once this condi= tion disappears. > 5. We are looking for a solution that is: > - Based on the base BFD spec (RFC 5880) - among other reasons becaus= e of its operational simplicity > - Operates normally in the presence of LACP and, optionally, may ope= rate normally if LACP is not used. > > This is very close to what I've written 3 weeks ago in my message to the l= ist - see http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg01151.html= . > There is an implicit "implementation sanity" assumption here, e.g., that i= f the link has been found to be bi-directionally collecting and distributing= , any packet LAG receives from its MAC client and decides to transmit via su= ch a link would be received by the peer MAC client at the other end. > > Could we take this problem statement as the starting point? If not, what,= in your opinion, is the problem we try to address? > > Regards, > Sasha > > >> -----Original Message----- >> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On >> Behalf Of Jeffrey Haas >> Sent: Monday, January 09, 2012 4:04 PM >> To: Tom Sanders >> Cc: rtg-bfd@ietf.org >> Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was >> BFD on LAG interfaces)) >> >> Tom, >> >> On Mon, Jan 09, 2012 at 02:11:05PM +0530, Tom Sanders wrote: >>> I would not want to restrict ourselves by merely saying "forwarding IP >>> traffic". I dont see why a solution to preclude the possibility of >>> supporting VPLS or VPWS in which case one could have a LAG thats used >>> for forwarding L2 frames. >>> >>> The idea is to get rid of LACP. The idea is to use BFD for fast >>> detection since folks know and understand BFD. We could have achieved >>> the same using ethernet OAM but folks did not want to do that. >> >> I believe I strongly disagree with the idea we're trying to get rid of LA= CP. >> However, moving this back to requirements it can be observed we could >> accomplish the goal making sure IP traffic is delivered across the link >> either by: >> 1. Testing the IP forwarding ability of a given link. >> 2. Testing the frame forwarding ability of a given link. >> >> 2 seems to be closer to what you're looking for. BFD over Ethernet in su= ch >> a case would work here. It could then inform protocols such as LACP so i= t >> could converge faster. >> >> One of the reasons I think 1 is a better requirement is that when we're >> talking about aggregate links (regardless of link layer type), the operat= ion >> we're really concerned about is whether we can forward our higher layer >> traffic over it. This not only involves ensuring that the logical aggreg= ate >> link is presented to the implementation but whether the implementation >> can >> use it for that purpose. >> >> Put a slightly different way, just because you have a LAG doesn't mean th= at >> your forwarding is working over a component. I suspect any number of >> operators could pick their favorite bug where this has happened. >> >> Please note that I'm not suggesting we try to verify load balancing for L= AG >> members. Doing so is wildly out of scope for BFD. >> >>> AS i mentioned earlier, I think we'll be very myopic if we restrict >>> ourselves to IP unicast traffic. What prevents us from using that link >>> for multicast traffic or L2 traffic? >> >> The goal is to exercise the forwarding path for the service protected by >> BFD. If your traffic is IPv4 unicast, your BFD session should be as well= . >> If you traffic is MPLS, ditto. >> >> While I'm unclear how many implementations actually do this, it is arguab= le >> that if you're protecting a given CoS for IPv4 unicast, you should have a >> distinct IPv4 unicast BFD session using that CoS. This is because queuei= ng >> and forwarding hardware may forward differently and you want to know if >> you >> get bi-directional forwarding for that CoS within your session's toleranc= e. >> However, I suspect most vendors simply choose to go with fate sharing of >> the >> address family; it minimizes the sessions you need. >> >> Similarly, when trying to provide feedback for LACP, one design choice >> could >> be to use the fate of IPv4 forwarding on a component to decide a LAG >> member >> is up or down based on fate sharing. A somewhat similar choice is faced >> when protecting IS-IS sessions on a link: IS-IS is not IP traffic. >> >> -- Jeff > > > This e-mail message is intended for the recipient only and contains inform= ation 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. > -- 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 jhaas@slice.pfrc.org Mon Jan 9 16:31:05 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3647321F8530 for ; Mon, 9 Jan 2012 16:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.939 X-Spam-Level: X-Spam-Status: No, score=-101.939 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StVwL-kMP6Gd for ; Mon, 9 Jan 2012 16:31:04 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B96FC21F852C for ; Mon, 9 Jan 2012 16:31:04 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6DE50224072; Tue, 10 Jan 2012 00:31:04 +0000 (UTC) Date: Mon, 9 Jan 2012 19:31:04 -0500 From: Jeffrey Haas To: Alexander Vainshtein Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Message-ID: <20120110003104.GR7464@slice> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> <885C6A9D-D35D-4388-9EE7-2A58F2F06D3E@sniff.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:31:05 -0000 Sasha, On Mon, Jan 09, 2012 at 07:59:46PM +0200, Alexander Vainshtein wrote: > Lots of thanks for a prompt response and an excellent example of what could go wrong ("layer-3 hw on I/O card 2 is broken"). And for what it's worth, Marc did a fine job summarizing one of the concerns I'm trying to cover in the requirements. > I can take it a bit further: Please consider a 1-hop IPv4/IPv6 BFD implementation (RFC 5881) where received BFD packets are identified early in the forwarding path and sent to the appropriate HW or SW entity, while "regular" IPv4 packets (with destination addresses not owned by the receiving router) are sent for the longest prefix match look-up in a corrupted table ("broken HW" or "SW bug") and, as a consequence, are black-holed. There is even no need in LAG... > > Please note that since IP and MPLS lookups are in different tables, IP traffic with the same destination addresses but encapsulated in MPLS could be perfectly healthy... If the expected traffic is MPLS encapsulated IP, BFD should in such a case be using MPLS as a transport. > In other words, it is important to agree in advance which kind of failures you want to detect. > > To my taste, 1-hop BFD reliably covers the media between the pair of adjacent routers (be it a physical link, a LAN or something else). Once your BFD packets have been successfully received by the router, the actual coverage is implementation-specific. > > Did I miss something? We largely agree. The point of my suggested requirements is that if any IPv4, for example, can get through the component link, you're doing as well as you can. Doing BFD at layer 2 tells us that the link is up but not necessarily that IP forwarding is working at all. But it's one step closer to the traffic that would be passing through the link. To pollute this response slightly, please also consider viability of deployment from a standards basis. IEEE was, per prior discussion with Dave Ward, not very receptive to doing BFD at layer 2. If our only real goal is end to end link validation or as an adjunct to LACP, I suspect IEEE's response would be "just use Ethernet OAM". Part of the reason we're having this discussion is because IP service providers are not too keen for any number of reasons to deploy Ethernet OAM. If they are, their solution space is already covered. A secondary consideration is also re-use of any standard for other types of link aggregates. Ethernet is the current case with the most interest, so it makes sense to start there. However, we'll probably consider others as well. -- Jeff From manav.bhatia@alcatel-lucent.com Mon Jan 9 16:38:48 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC2921F85C4 for ; Mon, 9 Jan 2012 16:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 0NQmSjyvpsCp for ; Mon, 9 Jan 2012 16:38:47 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBB621F84FB for ; Mon, 9 Jan 2012 16:38:47 -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 q0A0ce4O005597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2012 18:38:42 -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 q0A0ccKj000782 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Jan 2012 06:08:38 +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, 10 Jan 2012 06:08:38 +0530 From: "Bhatia, Manav (Manav)" To: Pablo Frank , Jeffrey Haas Date: Tue, 10 Jan 2012 06:04:06 +0530 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczO7AvW3QCJo53SSiSfaSxUaec/BgAQwctA Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A327F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:38:48 -0000 Hi Pablo, [clipped] > If the goal is to monitor the L3 forwarding path, then I don't think the = proposed=20 > solutions in the draft do that either. Injecting IP unicast or multicast= frames=20 > directly into the member links of a LAG does not necessarily test the L3 = datapath=20 > because normal packets would be subject to the LAG distribution algorithm= . And=20 > that's kinda the rub. If I want to ensure that my L3 frames will cross a= LAG correctly,=20 > I need to have visibility into the LAG distributor and source frames that= will predictably=20 > test the individual legs of the LAG. For IP, this means varying the IP s= rc/dst and UDP=20 > src/dst (how would you do this with the normal IP BFD encap?). For MPLS = sections,=20 This is incorrect. You don't need to do anything of this sort.=20 Its implementation specific and I am sure all vendors can send IP/UDP packe= ts with the same source IP/dest IP pair over different ports of the LAG. Cheers, Manav= From jhaas@slice.pfrc.org Mon Jan 9 16:45:04 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AD921F8605 for ; Mon, 9 Jan 2012 16:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.968 X-Spam-Level: X-Spam-Status: No, score=-101.968 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yaUAu5emk+N for ; Mon, 9 Jan 2012 16:45:04 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id D5CFD21F85FD for ; Mon, 9 Jan 2012 16:45:03 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7BF9F224070; Tue, 10 Jan 2012 00:45:03 +0000 (UTC) Date: Mon, 9 Jan 2012 19:45:03 -0500 From: Jeffrey Haas To: Pablo Frank Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Message-ID: <20120110004503.GS7464@slice> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:45:04 -0000 Pablo, On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank wrote: > If the goal is to monitor the L3 forwarding path, then I don't think the > proposed solutions in the draft do that either. Injecting IP unicast or > multicast frames directly into the member links of a LAG does not > necessarily test the L3 datapath because normal packets would be subject to > the LAG distribution algorithm. And that's kinda the rub. If I want to > ensure that my L3 frames will cross a LAG correctly, I need to have > visibility into the LAG distributor and source frames that will predictably > test the individual legs of the LAG. For IP, this means varying the IP > src/dst and UDP src/dst (how would you do this with the normal IP BFD > encap?). For MPLS sections, I suppose one could vary the entropy label. > Of course, all this assumes that the behaviour of the distributor is known > and predictable. I'm just not sure how you can write a standard around > this. See other responses for my thoughts on layer 2 BFD. I completely agree with you with regard to layer 3. We fundamentally cannot exercise the load balancer in a useful way with BFD. I don't think we should try. What we do get out of layer 3 BFD on a per link basis is: - The link is up. - It is able to pass our traffic of interest. > But there's an additional issue with running BFD at the L3 level instead of > L2. If that's what you choose to do then I don't think that a L3 BFD > session has any business trying to influence the state of LACP that's > running down at the link layer. I think if you choose to implement a > "LAG-aware" L3 BFD session, then all you should be doing with the state > information is influencing your L3 operational state (and taking corrective > action at L3 such as protection switching, re-routing, etc.). That is a fair observation. By previous analogy to protecting IS-IS sessions, vendors will use IPv4 BFD state to influence IS-IS despite the fact that they're operating over different encapsulations. It could also be fairly pointed out that layer 2 BFD for our per-link case may also be good enough. It is also potentially arguable that if you have a per-link BFD session for IPv4 and one for IPv6, if IPv6 stops working you probably don't want to tear the link down. However, if the load balancer can take as inputs for its hash the per-address family health of the link, the load balancer can choose to do Something Appropriate. So, to address your point, if we use BFD over layer 3, I believe that we can get "good enough" link health in spite of not using the same transport as LACP *and* that we get a useful input to LAG traffic balancers as well. And to reiterate, I agree with you that we're not fully exercising the load balancer using BFD. > It seems to me that we can't have our cake and eat it too. There isn't a > single solution that will solve both the L2 and L3 problem domains in one > shot, nor should we try to achieve that. It seems to me that the L2 > solution should aim to solve the LACP slow convergence problem and not > attempt to verify L3 connectivity. The IETF could try solving this with a > L2 BFD/LAG link approach but an IEEE solution is equally valid and they > likely *should* own this problem. We will certainly be working with IEEE to help refine the problem and solution spaces. > There might be a room for a L3 > "LAG-aware" solution but the goal here is verifying L3 operational state > and it should certainly NOT be trying to influence the state of the L2 LAG > members. This point is certainly one of the issues I was hoping we'd drive to conclusion by discussing requirements. -- Jeff From jhaas@slice.pfrc.org Mon Jan 9 16:55:42 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDB511E8080 for ; Mon, 9 Jan 2012 16:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.993 X-Spam-Level: X-Spam-Status: No, score=-101.993 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yTqu+y-nlra for ; Mon, 9 Jan 2012 16:55:42 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 226A221F8681 for ; Mon, 9 Jan 2012 16:55:42 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E002222411C; Tue, 10 Jan 2012 00:55:41 +0000 (UTC) Date: Mon, 9 Jan 2012 19:55:41 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: draft-bhatia-bfd-hmac-sha-00.txt Message-ID: <20120110005541.GU7464@slice> References: <7C362EEF9C7896468B36C9B79200D8350D005EAB59@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D005EAB59@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 00:55:42 -0000 In spite of the silence on this draft, the material covered by it has received review in similar forms outside of the BFD working group. Much like MIBs, crypto doesn't usually get much attention until last call. :-) Since the material in this draft is covered by working group charter, please submit the draft as draft-ietf-bfd-. We'll work on getting further feedback from the group and other security related people. -- Jeff On Sun, Oct 09, 2011 at 10:30:34PM +0530, Bhatia, Manav (Manav) wrote: > Dacheng, Vishwas and I have submitted a new draft that addresses the item 2c in the updated BFD charter - Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. > > Would be great if the WG can review this document and provide their feedback. > > The draft is available here: > http://www.ietf.org/internet-drafts/draft-bhatia-bfd-hmac-sha-00.txt > > Cheers, Manav > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, October 09, 2011 10:24 PM > To: Bhatia, Manav (Manav) > Cc: vishwas.manral@hp.com; zhangdacheng@huawei.com; Bhatia, Manav (Manav) > Subject: New Version Notification for draft-bhatia-bfd-hmac-sha-00.txt > > A new version of I-D, draft-bhatia-bfd-hmac-sha-00.txt has been successfully submitted by Manav Bhatia and posted to the IETF repository. > > Filename: draft-bhatia-bfd-hmac-sha > Revision: 00 > Title: Authenticating BFD using HMAC-SHA-2 procedures > Creation date: 2011-10-09 > WG ID: Individual Submission > Number of pages: 10 > > Abstract: > This document describes how Hashed Message Authentication Mode (HMAC) > in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can > be used for authenticating Bidirectional Forwarding Detection (BFD). > It uses the Generic Cryptographic Authentication and Generic > Meticulous Cryptographic Authentication sections to carry the > authentication data. This updates, but does not supercede, the > cryptographic authentication mechanism specified in RFC 5880. > > > > > > The IETF Secretariat From internet-drafts@ietf.org Wed Jan 11 07:38:15 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D878621F86F9; Wed, 11 Jan 2012 07:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcap-APdhPbZ; Wed, 11 Jan 2012 07:38:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70ED21F85E4; Wed, 11 Jan 2012 07:37:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-hmac-sha-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120111153755.6076.59985.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 07:37:55 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:38:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Wo= rking Group of the IETF. Title : Authenticating BFD using HMAC-SHA-2 procedures Author(s) : Dacheng Zhang Manav Bhatia Vishwas Manral Filename : draft-ietf-bfd-hmac-sha-00.txt Pages : 10 Date : 2012-01-11 This document describes how Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can be used for authenticating Bidirectional Forwarding Detection (BFD). It uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bfd-hmac-sha-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-bfd-hmac-sha-00.txt From manav.bhatia@alcatel-lucent.com Wed Jan 11 07:50:52 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D3021F8633 for ; Wed, 11 Jan 2012 07:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 nvy7m23scNcK for ; Wed, 11 Jan 2012 07:50:52 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DB47621F862D for ; Wed, 11 Jan 2012 07:50:51 -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 q0BFol8u026658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Jan 2012 09:50:50 -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 q0BFolvO031462 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 11 Jan 2012 21:20:47 +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, 11 Jan 2012 21:20:47 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Wed, 11 Jan 2012 21:20:45 +0530 Subject: Authenticating BFD using HMAC-SHA-2 procedures Thread-Topic: Authenticating BFD using HMAC-SHA-2 procedures Thread-Index: AczQeMevYXlRb5bSTZib+52iVeKwZw== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A3772@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.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, 11 Jan 2012 15:50:52 -0000 Hi, We have posted the draft-ietf-bfd- version for authenticating BFD using SHA= 2 algorithms. This is very similar to what has been done for OSPFv2, IS-IS, OSPFv3, and o= ther routing protocols. Cheers, Manav -- From: internet-drafts@ietf.org=20 To: i-d-announce@ietf.org=20 Reply-to: internet-drafts@ietf.org=20 Subject: I-D Action: draft-ietf-bfd-hmac-sha-00.txt=20 X-RSN: 1/0/935/40947/44333=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Wo= rking Group of the IETF.=20 =20 Title : Authenticating BFD using HMAC-SHA-2 procedures=20 Author(s) : Dacheng Zhang=20 Manav Bhatia=20 Vishwas Manral=20 Filename : draft-ietf-bfd-hmac-sha-00.txt=20 Pages : 10=20 Date : 2012-01-11=20 =20 This document describes how Hashed Message Authentication Mode (HMAC)=20 in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can=20 be used for authenticating Bidirectional Forwarding Detection (BFD).=20 It uses the Generic Cryptographic Authentication and Generic=20 Meticulous Cryptographic Authentication sections to carry the=20 authentication data. This updates, but does not supercede, the=20 cryptographic authentication mechanism specified in RFC 5880.=20 =20 =20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-ietf-bfd-hmac-sha-00.txt=20 =20 Internet-Drafts are also available by anonymous FTP at:=20 ftp://ftp.ietf.org/internet-drafts/=20 =20 This Internet-Draft can be retrieved at:=20 ftp://ftp.ietf.org/internet-drafts/draft-ietf-bfd-hmac-sha-00.txt=20 =20 _______________________________________________=20 I-D-Announce mailing list=20 I-D-Announce@ietf.org=20 https://www.ietf.org/mailman/listinfo/i-d-announce=20 Internet-Draft directories: http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20 =20 = From pabloisnot@gmail.com Wed Jan 11 09:38:29 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE7221F884B for ; Wed, 11 Jan 2012 09:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[AWL=0.618, 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 TLHyZDGuVf75 for ; Wed, 11 Jan 2012 09:38:28 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A721F86C4 for ; Wed, 11 Jan 2012 09:38:28 -0800 (PST) Received: by obcuz6 with SMTP id uz6so1452720obc.31 for ; Wed, 11 Jan 2012 09:38:25 -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=T1oTzfNpoCAyz8zMnjTMLztcEZwe1vDbr4loZCkTX9s=; b=E00dMK6QPvGRWR2hATDwrSRd7ohxb0rQz1M4lfpRbFvzXA92KdUkoTSwgyaBFtEMYI u3PPUwppO1wMgat95HkBIDqOFI2ERfee/2A63yGdruYqrCkbrs7LD2iTH0fcG24kLJUG yXu9Cxhd4Rzo5cszO1kUIObX1eQjuACjKTFqU= MIME-Version: 1.0 Received: by 10.182.226.6 with SMTP id ro6mr193751obc.3.1326303505204; Wed, 11 Jan 2012 09:38:25 -0800 (PST) Received: by 10.182.159.6 with HTTP; Wed, 11 Jan 2012 09:38:25 -0800 (PST) In-Reply-To: <20120110004503.GS7464@slice> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> <20120110004503.GS7464@slice> Date: Wed, 11 Jan 2012 12:38:25 -0500 Message-ID: Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) From: Pablo Frank To: Jeffrey Haas Content-Type: multipart/alternative; boundary=f46d04462f884ac71704b644191b Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:38:29 -0000 --f46d04462f884ac71704b644191b Content-Type: text/plain; charset=ISO-8859-1 Hi Jeff See PF>> below On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas wrote: > Pablo, > > On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank wrote: > > If the goal is to monitor the L3 forwarding path, then I don't think the > > proposed solutions in the draft do that either. Injecting IP unicast or > > multicast frames directly into the member links of a LAG does not > > necessarily test the L3 datapath because normal packets would be subject > to > > the LAG distribution algorithm. And that's kinda the rub. If I want to > > ensure that my L3 frames will cross a LAG correctly, I need to have > > visibility into the LAG distributor and source frames that will > predictably > > test the individual legs of the LAG. For IP, this means varying the IP > > src/dst and UDP src/dst (how would you do this with the normal IP BFD > > encap?). For MPLS sections, I suppose one could vary the entropy label. > > Of course, all this assumes that the behaviour of the distributor is > known > > and predictable. I'm just not sure how you can write a standard around > > this. > > See other responses for my thoughts on layer 2 BFD. > > I completely agree with you with regard to layer 3. We fundamentally > cannot > exercise the load balancer in a useful way with BFD. I don't think we > should try. > > What we do get out of layer 3 BFD on a per link basis is: > - The link is up. > - It is able to pass our traffic of interest. PF>> I guess it's the 2nd point that I'm skeptical about. If you are not going through the normal IP forwarding path, what exactly does it prove? If both sender and receiver are bypassing normal IP stack operation to send and receive these frames, it doesn't matter that they're IP encapsulated. They could be encapsulated in protocol foo and you could achieve the same thing. I guess, fundamentally, unless the L3 BFD is subject to the same forwarding rules as other L3 traffic, it doesn't prove anything more than just running BFD directly over L2. Even if you were to assign, say, link-local IP addresses to the individual links and exchange frames this way then all you're proving is that you can exchange packets in the link-local subnet. The IP routes that point out the LAG interface (as opposed to the individual legs) might still be busted for any number of reasons. regards, Pablo --f46d04462f884ac71704b644191b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Jeff

See PF>> below

On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas <<= a href=3D"mailto:jhaas@pfrc.org">jhaas@pfrc.org> wrote:
Pablo,

On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank wrote:
> If the goal is to monitor the L3 forwarding path, then I don't thi= nk the
> proposed solutions in the draft do that either. =A0Injecting IP unicas= t or
> multicast frames directly into the member links of a LAG does not
> necessarily test the L3 datapath because normal packets would be subje= ct to
> the LAG distribution algorithm. =A0And that's kinda the rub. =A0If= I want to
> ensure that my L3 frames will cross a LAG correctly, I need to have > visibility into the LAG distributor and source frames that will predic= tably
> test the individual legs of the LAG. =A0For IP, this means varying the= IP
> src/dst and UDP src/dst (how would you do this with the normal IP BFD<= br> > encap?). =A0For MPLS sections, I suppose one could vary the entropy la= bel.
> =A0Of course, all this assumes that the behaviour of the distributor i= s known
> and predictable. =A0I'm just not sure how you can write a standard= around
> this.

See other responses for my thoughts on layer 2 BFD.

I completely agree with you with regard to layer 3. =A0We fundamentally can= not
exercise the load balancer in a useful way with BFD. =A0I don't think w= e
should try.

What we do get out of layer 3 BFD on a per link basis is:
- The link is up.
- It is able to pass our traffic of interest.

PF>> I guess it's the 2nd point that I'm skeptical about. = =A0If you are not going through the normal IP forwarding path, what exactly= does it prove? If both sender and receiver are bypassing normal IP stack o= peration to send and receive these frames, it doesn't matter that they&= #39;re IP encapsulated. =A0They could be encapsulated in protocol foo and y= ou could achieve the same thing. =A0I guess, fundamentally, unless the L3 B= FD is subject to the same forwarding rules as other L3 traffic, it doesn= 9;t prove anything more than just running BFD directly over L2. =A0

Even if you were to assign, say, link-local IP addresse= s to the individual links and exchange frames this way then all you're = proving is that you can exchange packets in the link-local subnet. =A0The I= P routes that point out the LAG interface (as opposed to the individual leg= s) might still be busted for any number of reasons.

regards,
Pablo

--f46d04462f884ac71704b644191b-- From gregory.mirsky@ericsson.com Wed Jan 11 12:12:06 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F4A21F85D7 for ; Wed, 11 Jan 2012 12:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a99j4fw583rc for ; Wed, 11 Jan 2012 12:12:00 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 93FB521F8585 for ; Wed, 11 Jan 2012 12:12:00 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0BKBwSW012872; Wed, 11 Jan 2012 14:11:59 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 11 Jan 2012 15:11:52 -0500 From: Gregory Mirsky To: Pablo Frank , Jeffrey Haas Date: Wed, 11 Jan 2012 15:11:51 -0500 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczQh+QGzigu0PjKTy2Otuw3sI8SxQAFII1g Message-ID: References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> <20120110004503.GS7464@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13229989EE8EUSAACMS0715e_" MIME-Version: 1.0 Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:12:06 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13229989EE8EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Pablo, et al., I think that since RFC 5880 BFD is not using Up/Down MEP model fate sharing= within a node is implementation specific. Regards, Greg ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Pablo Frank Sent: Wednesday, January 11, 2012 9:38 AM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD= on LAG interfaces)) Hi Jeff See PF>> below On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas > wrote: Pablo, On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank wrote: > If the goal is to monitor the L3 forwarding path, then I don't think the > proposed solutions in the draft do that either. Injecting IP unicast or > multicast frames directly into the member links of a LAG does not > necessarily test the L3 datapath because normal packets would be subject = to > the LAG distribution algorithm. And that's kinda the rub. If I want to > ensure that my L3 frames will cross a LAG correctly, I need to have > visibility into the LAG distributor and source frames that will predictab= ly > test the individual legs of the LAG. For IP, this means varying the IP > src/dst and UDP src/dst (how would you do this with the normal IP BFD > encap?). For MPLS sections, I suppose one could vary the entropy label. > Of course, all this assumes that the behaviour of the distributor is kno= wn > and predictable. I'm just not sure how you can write a standard around > this. See other responses for my thoughts on layer 2 BFD. I completely agree with you with regard to layer 3. We fundamentally canno= t exercise the load balancer in a useful way with BFD. I don't think we should try. What we do get out of layer 3 BFD on a per link basis is: - The link is up. - It is able to pass our traffic of interest. PF>> I guess it's the 2nd point that I'm skeptical about. If you are not g= oing through the normal IP forwarding path, what exactly does it prove? If = both sender and receiver are bypassing normal IP stack operation to send an= d receive these frames, it doesn't matter that they're IP encapsulated. Th= ey could be encapsulated in protocol foo and you could achieve the same thi= ng. I guess, fundamentally, unless the L3 BFD is subject to the same forwa= rding rules as other L3 traffic, it doesn't prove anything more than just r= unning BFD directly over L2. Even if you were to assign, say, link-local IP addresses to the individual = links and exchange frames this way then all you're proving is that you can = exchange packets in the link-local subnet. The IP routes that point out th= e LAG interface (as opposed to the individual legs) might still be busted f= or any number of reasons. regards, Pablo --_000_FE60A4E52763E84B935532D7D9294FF13229989EE8EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Pablo, et al.,
I think that since RFC 5880 BFD is not using Up/Do= wn MEP=20 model fate sharing within a node is implementation specific.<= /DIV>
 
  &n= bsp; Regards,
        Greg

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Pablo=20 Frank
Sent: Wednesday, January 11, 2012 9:38 AM
To: Jef= frey=20 Haas
Cc: rtg-bfd@ietf.org
Subject: Re: BFD on LAG=20 requirements (was Re: Multicast vs Unicast (was BFD on LAG=20 interfaces))

Hi Jeff

See PF>> below

On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas <jhaas@pfrc.org>=20 wrote:
Pablo,

On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank= =20 wrote:
> If the goal is to monitor the L3 forwarding path, then I d= on't=20 think the
> proposed solutions in the draft do that either.=20  Injecting IP unicast or
> multicast frames directly into the= =20 member links of a LAG does not
> necessarily test the L3 datapath=20 because normal packets would be subject to
> the LAG distribution=20 algorithm.  And that's kinda the rub.  If I want to
> ens= ure=20 that my L3 frames will cross a LAG correctly, I need to have
>=20 visibility into the LAG distributor and source frames that will=20 predictably
> test the individual legs of the LAG.  For IP, th= is=20 means varying the IP
> src/dst and UDP src/dst (how would you do th= is=20 with the normal IP BFD
> encap?).  For MPLS sections, I suppos= e one=20 could vary the entropy label.
>  Of course, all this assumes t= hat=20 the behaviour of the distributor is known
> and predictable.  = I'm=20 just not sure how you can write a standard around
>=20 this.

See other responses for my thoughts on layer 2=20 BFD.

I completely agree with you with regard to layer 3.  We= =20 fundamentally cannot
exercise the load balancer in a useful way with B= FD.=20  I don't think we
should try.

What we do get out of layer = 3 BFD=20 on a per link basis is:
- The link is up.
- It is able to pass our= =20 traffic of interest.

PF>> I guess it's the 2nd point that I'm skeptical about.  = If=20 you are not going through the normal IP forwarding path, what exactly does = it=20 prove? If both sender and receiver are bypassing normal IP stack operation = to=20 send and receive these frames, it doesn't matter that they're IP encapsulat= ed.=20  They could be encapsulated in protocol foo and you could achieve the = same=20 thing.  I guess, fundamentally, unless the L3 BFD is subject to the sa= me=20 forwarding rules as other L3 traffic, it doesn't prove anything more than j= ust=20 running BFD directly over L2.  

Even if you were to assign, say, link-local IP addresses to the indivi= dual=20 links and exchange frames this way then all you're proving is that you can= =20 exchange packets in the link-local subnet.  The IP routes that point o= ut=20 the LAG interface (as opposed to the individual legs) might still be busted= for=20 any number of reasons.

regards,
Pablo

--_000_FE60A4E52763E84B935532D7D9294FF13229989EE8EUSAACMS0715e_-- From manav.bhatia@alcatel-lucent.com Wed Jan 11 15:32:47 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4321F85EA for ; Wed, 11 Jan 2012 15:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.016, 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 cYxatnjTwQyb for ; Wed, 11 Jan 2012 15:32:46 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5CD21F85D8 for ; Wed, 11 Jan 2012 15:32:45 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0BNWfEf009025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 17:32:43 -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 q0BNWekt028413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Jan 2012 05:02:40 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 12 Jan 2012 05:02:40 +0530 From: "Bhatia, Manav (Manav)" To: Pablo Frank , Jeffrey Haas Date: Thu, 12 Jan 2012 05:02:38 +0530 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczQh9js3JVgk8dvSuqjYav/6lT4CwALiQqw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A37A8@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> <20120110004503.GS7464@slice> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350D028A37A8INBANSXCHMBSA_" 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: Wed, 11 Jan 2012 23:32:47 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350D028A37A8INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pablo, I disagree with your conclusion that micro BFD sessions using L3 encapsulat= ion does not get us anything. Lets look at the two most widely deployed routing protocols, IS-IS and OSPF= . IS-IS packets don't follow the exact data path as the IP packets (since IS-= IS uses L2 encap) and yet once the IS-IS adjacency goes up we trust that we= can use that link for IP forwarding. Even OSPF for that matter does not fo= llow the exact same data path as IP unicast packets since OSPF packets are = multicast (except for DDs which are unicast). In both cases the protocols d= on't follow the same data path as IP unicast and yet we conclude that the I= P routes are reachable based on the information provided by these protocols= . L3 encap micro BFD sessions will tell you that: (1) The link is up (2) The receiver is able to process L3 packets arriving on that link Its imperative that we ensure that each link is able to process L3 packets = since each link [1] will be used for L3 forwarding. And by running BFD on e= ach member link (via micro BFD sessions) we ensure exactly that. And this i= s also precisely the reason why i believe that using multicast encap for mi= cro BFD sessions is nearly as good as using unicast encap. Cheers, Manav [1] The details of how each link gets used is implementation specific and i= ts usually decided based on a hash of certain well known fields from the da= ta packet. ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Pablo Frank Sent: Wednesday, January 11, 2012 11:08 PM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD= on LAG interfaces)) Hi Jeff See PF>> below On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas > wrote: Pablo, On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank wrote: > If the goal is to monitor the L3 forwarding path, then I don't think the > proposed solutions in the draft do that either. Injecting IP unicast or > multicast frames directly into the member links of a LAG does not > necessarily test the L3 datapath because normal packets would be subject = to > the LAG distribution algorithm. And that's kinda the rub. If I want to > ensure that my L3 frames will cross a LAG correctly, I need to have > visibility into the LAG distributor and source frames that will predictab= ly > test the individual legs of the LAG. For IP, this means varying the IP > src/dst and UDP src/dst (how would you do this with the normal IP BFD > encap?). For MPLS sections, I suppose one could vary the entropy label. > Of course, all this assumes that the behaviour of the distributor is kno= wn > and predictable. I'm just not sure how you can write a standard around > this. See other responses for my thoughts on layer 2 BFD. I completely agree with you with regard to layer 3. We fundamentally canno= t exercise the load balancer in a useful way with BFD. I don't think we should try. What we do get out of layer 3 BFD on a per link basis is: - The link is up. - It is able to pass our traffic of interest. PF>> I guess it's the 2nd point that I'm skeptical about. If you are not g= oing through the normal IP forwarding path, what exactly does it prove? If = both sender and receiver are bypassing normal IP stack operation to send an= d receive these frames, it doesn't matter that they're IP encapsulated. Th= ey could be encapsulated in protocol foo and you could achieve the same thi= ng. I guess, fundamentally, unless the L3 BFD is subject to the same forwa= rding rules as other L3 traffic, it doesn't prove anything more than just r= unning BFD directly over L2. Even if you were to assign, say, link-local IP addresses to the individual = links and exchange frames this way then all you're proving is that you can = exchange packets in the link-local subnet. The IP routes that point out th= e LAG interface (as opposed to the individual legs) might still be busted f= or any number of reasons. regards, Pablo --_000_7C362EEF9C7896468B36C9B79200D8350D028A37A8INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Pablo,
 
I disagree with your conclusion that micro BFD ses= sions=20 using L3 encapsulation does not get us anything.
 
Lets look at the two most widely deployed rou= ting=20 protocols, IS-IS and OSPF.
 
IS-IS packets don't follow the exact data path as = the IP=20 packets (since IS-IS uses L2 encap) and yet once the IS-IS adjacency goes u= p we=20 trust that we can use that link for IP forwarding. Even OSPF for that matte= r=20 does not follow the exact same data path as IP unicast packets since OSPF=20 packets are multicast (except for DDs which are unicast). In both cases the= =20 protocols don't follow the same data path as IP unicast and yet we conclude= that=20 the IP routes are reachable based on the information provided by these=20 protocols.
 
L3 encap micro BFD sessions will tell you=20 that:
 
(1) The link is up
(2) The receiver is able to process L3 packets arr= iving on=20 that link
 
Its imperative that we ensure that each link is ab= le to=20 process L3 packets since each link [1] will be used for L3 forwarding. And = by=20 running BFD on each member link (via micro BFD sessions) we ensure exactly = that.=20 And this is also precisely the reason why i believe that using multicast en= cap=20 for micro BFD sessions is nearly as good as using unicast=20 encap.
 
Cheers, Manav
 
[1] The details of how each link gets used is=20 implementation specific and its usually decided based on a hash of certain = well=20 known fields from the data packet.

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Pablo=20 Frank
Sent: Wednesday, January 11, 2012 11:08 PM
To: Je= ffrey=20 Haas
Cc: rtg-bfd@ietf.org
Subject: Re: BFD on LAG=20 requirements (was Re: Multicast vs Unicast (was BFD on LAG=20 interfaces))

Hi Jeff

See PF>> below

On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas <jhaas@pfrc.org>=20 wrote:
Pablo,

On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank= =20 wrote:
> If the goal is to monitor the L3 forwarding path, then I d= on't=20 think the
> proposed solutions in the draft do that either.=20  Injecting IP unicast or
> multicast frames directly into the= =20 member links of a LAG does not
> necessarily test the L3 datapath=20 because normal packets would be subject to
> the LAG distribution=20 algorithm.  And that's kinda the rub.  If I want to
> ens= ure=20 that my L3 frames will cross a LAG correctly, I need to have
>=20 visibility into the LAG distributor and source frames that will=20 predictably
> test the individual legs of the LAG.  For IP, th= is=20 means varying the IP
> src/dst and UDP src/dst (how would you do th= is=20 with the normal IP BFD
> encap?).  For MPLS sections, I suppos= e one=20 could vary the entropy label.
>  Of course, all this assumes t= hat=20 the behaviour of the distributor is known
> and predictable.  = I'm=20 just not sure how you can write a standard around
>=20 this.

See other responses for my thoughts on layer 2=20 BFD.

I completely agree with you with regard to layer 3.  We= =20 fundamentally cannot
exercise the load balancer in a useful way with B= FD.=20  I don't think we
should try.

What we do get out of layer = 3 BFD=20 on a per link basis is:
- The link is up.
- It is able to pass our= =20 traffic of interest.

PF>> I guess it's the 2nd point that I'm skeptical about.  = If=20 you are not going through the normal IP forwarding path, what exactly does = it=20 prove? If both sender and receiver are bypassing normal IP stack operation = to=20 send and receive these frames, it doesn't matter that they're IP encapsulat= ed.=20  They could be encapsulated in protocol foo and you could achieve the = same=20 thing.  I guess, fundamentally, unless the L3 BFD is subject to the sa= me=20 forwarding rules as other L3 traffic, it doesn't prove anything more than j= ust=20 running BFD directly over L2.  

Even if you were to assign, say, link-local IP addresses to the indivi= dual=20 links and exchange frames this way then all you're proving is that you can= =20 exchange packets in the link-local subnet.  The IP routes that point o= ut=20 the LAG interface (as opposed to the individual legs) might still be busted= for=20 any number of reasons.

regards,
Pablo

--_000_7C362EEF9C7896468B36C9B79200D8350D028A37A8INBANSXCHMBSA_-- From jhaas@slice.pfrc.org Thu Jan 12 06:48:50 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1525F21F85F4 for ; Thu, 12 Jan 2012 06:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9c6P2GvE4d6 for ; Thu, 12 Jan 2012 06:48:49 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A41AD21F8604 for ; Thu, 12 Jan 2012 06:48:49 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 50E58224141; Thu, 12 Jan 2012 14:48:48 +0000 (UTC) Date: Thu, 12 Jan 2012 09:48:48 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Message-ID: <20120112144847.GX7464@slice> References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> <20120110004503.GS7464@slice> <7C362EEF9C7896468B36C9B79200D8350D028A37A8@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A37A8@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 14:48:50 -0000 On Thu, Jan 12, 2012 at 05:02:38AM +0530, Bhatia, Manav (Manav) wrote: > IS-IS packets don't follow the exact data path as the IP packets (since IS-IS uses L2 encap) and yet once the IS-IS adjacency goes up we trust that we can use that link for IP forwarding. Even OSPF for that matter does not follow the exact same data path as IP unicast packets since OSPF packets are multicast (except for DDs which are unicast). In both cases the protocols don't follow the same data path as IP unicast and yet we conclude that the IP routes are reachable based on the information provided by these protocols. I'm going to pick on the OSPF case for a second. There have been about three incidences I can remember over the years where OSPF was failing to work right for me that were eventually diagnosed to be multicast vs. unicast reachability issues on the exact same link. In these cases, the issue was outright buggy implementation. (And in 2/3 of the cases, resetting the interface cleared the problem.) While I can agree with Pablo that we're not testing traffic *through* the box but only *to* the box (a very shallow test for a box we probably want to use as a transit router), I still think testing to the layer 3 is one step better than not. Bugs such as the ones discussed above make me leery of doing otherwise. (And we're not going to even talk about IS-IS bugs where IP wasn't up...) -- Jeff From Alexander.Vainshtein@ecitele.com Thu Jan 12 08:18:09 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309F421F8646 for ; Thu, 12 Jan 2012 08:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.537 X-Spam-Level: X-Spam-Status: No, score=-4.537 tagged_above=-999 required=5 tests=[AWL=0.666, 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 qcqMVT8p8y5K for ; Thu, 12 Jan 2012 08:18:08 -0800 (PST) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 3443D21F859A for ; Thu, 12 Jan 2012 08:18:08 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1326385046!55697885!1 X-Originating-IP: [147.234.242.235] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 31314 invoked from network); 12 Jan 2012 16:17:27 -0000 Received: from ilptbmg02-out.ecitele.com (HELO ilptbmg02.ecitele.com) (147.234.242.235) by server-4.tower-27.messagelabs.com with SMTP; 12 Jan 2012 16:17:27 -0000 X-AuditID: 93eaf2e8-b7fc36d000002072-27-4f0f08afb2f4 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg02.ecitele.com (Symantec Messaging Gateway) with SMTP id 09.41.08306.FA80F0F4; Thu, 12 Jan 2012 18:22:07 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Thu, 12 Jan 2012 18:18:05 +0200 From: Alexander Vainshtein To: Jeffrey Haas Date: Thu, 12 Jan 2012 18:18:03 +0200 Subject: RE: BFD on LAG requirements (was Re: Multicast vs. Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs. Unicast (was BFD on LAG interfaces)) Thread-Index: AczRRcLNsqWtDgegRAOsNgiRE5PCHQ== 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="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa0gUURjtzuxu42N0dnPzuhWME0UPV3RN2siVCAILZO1F1J8aZ6+7k7uz y86suf1JQyuTxBSkTNJEJEqxtCf2XCooQq0ksocgmpSpoD2NymYcM6P769zvnPM9Lt8lcEOH zkTwgoT8AutmdOGayqHxT+YLRLQ9qbgPs96+O6K11vT2aq0ff1wB6/CM4sGb2oyGhgks49mx y9osfFcBSGMFwSuxEqIdSORsTJafz2O5IEPzDhuTzNA+N8shDxIkG8P6fEhwMOnh9H8nTZbx Ao0EzuvgBaeN2bjVbrZaU9eYk5n0pYuTU9aGb3PxIo3MHpZ30x4kiqwT0XJkzyXcVTbYPdfX Y8x/e89aAOr1R0EYAalVcPBiCa7i+bCrt0V3FIQTBqodwKI7pzD1UgVgS2khpqh0lA22nn+j U3AMFQ9rJ0umME7lwOGXTVNYQy2Bl1tOaxQ8j8qG71tDuKrnYNf3BxoVJ8KnZb+m4iS1GTb+ aJ6KA7mLr4+aMDVnLHw5UIup3VGw4UbndKdG+L7/l1bVG+Hrwy1A1SfAuvbx6X5WwsYzH6bz 6+HDkwMa1RsH7559oSkHxupZJapn2atn2atn2euA5hyI490+KdvjTLKYvQEpEXG8hNwokfN6 WoG6Ge+ugVePl4cARQAmkrx+k7QbtGyeGPSEQByBMUbyiy7abojK9jqCLlZ07fYH3EgMAUjg TAxZ2RllN5AONrgf+b1/KKv8osdxUwTnlXdQkHanJCX9c2FiyVJuONNAOeUFy0XIh/x/rAsJ goHkhFJR70dOlJ/Du6W/NEaEKZUj5crMXFlDij7WI/JOlX8E4k2xpFYhKIVwBYQZr/INDkxO Tg6BWHnOeepQkfInmXEPyYkxOXGeQxlJlJd/hjIVAH5ZvWnfgqqy1vL7Y32Fuf36aIsnrSa1 6MiJS69jKuo2XAh9Xj12qG3PxsDt70Omtvhg7fr2TeyW6wsX9aTfMuzc4Xwqdvw80vahvtRS a0rYfrW5+KBFfycs73lE5pO21V571cS1YVtFbnrN49yBpnvfto1kBC1z6G5XYDS1ZJTem8Bo RBebvAL3i+xvP50q0eEDAAA= Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 16:18:09 -0000 Jeff hi, Your "buggy implementation stories" sound quite realistic. However I am not sure that BFD can provide a workaround for those. E.g., consider an implementation that first of all looks up the Destination= IP address of a received packet in a short list of "special" IP addresses (= ingress interface addresses, non-routable unicast and multicast addresses et= c.), sends matching packets to the appropriate entities and only then begins= the longest prefix match lookup in a suitable FIB (potentially holding hund= reds of K of prefixes). Bugs or HW failures in such an implementation could easily result in OSPF ad= jacency and 1-hop IPv4 BFD session monitoring this adjacency coming (and sta= ying) UP while transit IP traffic (or part thereof) would be lost. In other words, I am not sure whether your "one step further into the box" a= dds substantial value. Regards, Sasha > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On > Behalf Of Jeffrey Haas > Sent: Thursday, January 12, 2012 4:49 PM > To: Bhatia, Manav (Manav) > Cc: rtg-bfd@ietf.org > Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was > BFD on LAG interfaces)) > > On Thu, Jan 12, 2012 at 05:02:38AM +0530, Bhatia, Manav (Manav) wrote: > > IS-IS packets don't follow the exact data path as the IP packets (since= IS-IS > uses L2 encap) and yet once the IS-IS adjacency goes up we trust that we c= an > use that link for IP forwarding. Even OSPF for that matter does not follow > the exact same data path as IP unicast packets since OSPF packets are > multicast (except for DDs which are unicast). In both cases the protocols > don't follow the same data path as IP unicast and yet we conclude that the > IP routes are reachable based on the information provided by these > protocols. > > I'm going to pick on the OSPF case for a second. > > There have been about three incidences I can remember over the years > where > OSPF was failing to work right for me that were eventually diagnosed to be > multicast vs. unicast reachability issues on the exact same link. In thes= e > cases, the issue was outright buggy implementation. (And in 2/3 of the > cases, resetting the interface cleared the problem.) > > While I can agree with Pablo that we're not testing traffic *through* the > box but only *to* the box (a very shallow test for a box we probably want= to > use as a transit router), I still think testing to the layer 3 is one step > better than not. Bugs such as the ones discussed above make me leery of > doing otherwise. > > (And we're not going to even talk about IS-IS bugs where IP wasn't up...) > > -- Jeff 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 jhaas@slice.pfrc.org Thu Jan 12 10:19:46 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF4E21F8664 for ; Thu, 12 Jan 2012 10:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.047 X-Spam-Level: X-Spam-Status: No, score=-102.047 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ONj1dgIOD17 for ; Thu, 12 Jan 2012 10:19:45 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CE79021F865D for ; Thu, 12 Jan 2012 10:19:45 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7A70D22414A; Thu, 12 Jan 2012 18:19:44 +0000 (UTC) Date: Thu, 12 Jan 2012 13:19:44 -0500 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: IETF 83 meeting - call for presentations Message-ID: <20120112181944.GA7464@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:19:46 -0000 Given the level of discussion we've had on BFD over LAG members in the mailing list, we have an excellent reason to meet at the upcoming IETF 83 in Paris. I have requested a one hour time slot for the working group. This is a call for presentations for that session. The cutoff for -00 I-Ds is March 5. -- Jeff and Dave From aldrin.ietf@gmail.com Thu Jan 12 11:38:26 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E7721F869D for ; Thu, 12 Jan 2012 11:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.068, 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 oz2E8FuuXcnx for ; Thu, 12 Jan 2012 11:38:25 -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 289CA21F8664 for ; Thu, 12 Jan 2012 11:38:25 -0800 (PST) Received: by ggnr5 with SMTP id r5so1414623ggn.31 for ; Thu, 12 Jan 2012 11:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=GlxwjNFFcLr3kfe7vfnHaXtHuUq4oDFulDFOu63hOtU=; b=EKJGFfn5mZ5T0Dt0dSZ2xrkWfubetrAhXRjBM2JgeRaC/E/sFT6nImviga+0FA90b6 Q3WmGBPchwkTuczUFgovkWfoXqSZyrrDBELFRcTDarLC3lOUnC4zAzTwFoqavXEyxJrx WZQIu8mQdiZPXe0b2bMWeT1JIz3/XGC8GPEDQ= Received: by 10.50.196.228 with SMTP id ip4mr3983852igc.28.1326397103084; Thu, 12 Jan 2012 11:38:23 -0800 (PST) Received: from [192.168.253.225] ([12.207.18.42]) by mx.google.com with ESMTPS id r18sm20381781ibh.4.2012.01.12.11.38.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 11:38:21 -0800 (PST) References: <20120109004256.GM7464@slice> In-Reply-To: <20120109004256.GM7464@slice> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <01B60CFA-190B-42FD-ADE5-B791F6776022@gmail.com> X-Mailer: iPad Mail (9A405) From: Sam Aldrin Subject: Re: BFD MIB extension for MPLS-TP Date: Thu, 12 Jan 2012 11:38:21 -0800 To: Jeffrey Haas Cc: "draft-vkst-bfd-mpls-mib@tools.ietf.org" , "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:38:26 -0000 Hi Jeff, Thank you for your comments. Please see inline for my replies to your questi= ons. Agree to all of your suggestions and comments. Cheers Sam Sent from my iPad On Jan 8, 2012, at 4:42 PM, Jeffrey Haas wrote: > [Mostly writing as an individual contributor.] >=20 > On Thu, Dec 15, 2011 at 08:17:24PM -0800, Sam Aldrin wrote: >> We have submitted a new draft, BFD MIB extensions to support MPLS-TP, pri= or >> to IETF82 at Taipei. >>=20 >> The draft is located at >> http://datatracker.ietf.org/doc/draft-vkst-bfd-mpls-mib/ >>=20 >>=20 >> We have presented the draft in MPLS WG to get feedback from that WG. >>=20 >> As there was no WG session at Taipei, we are seeking feedback from BFD WG= >> over the mailing list. >>=20 >>=20 >> 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. >=20 > My first comment is that the object names in this MIB seem to strongly > suggest that this is a general extension MIB for BFD rather than are addin= g > MPLS-TP specific objects to the BFD MIB. E.g.: > bfdExtObjects > bfdSessExtTable > etc. >=20 > I would strongly suggest the object names be more specific in alluding to > MPLS-TP. %sam - agree. We will be changing the object names appropriately. As we are e= xtending to support MPLS in general, not just TP, we will change accordingly= . >=20 > SessionMapTypeTC should similarly note that it is associated with both BFD= > and MPLS-TP. Also, if there's any chance that this TC will see re-use, it= > should be placed in its own MIB at some point in the future. IMO, it's fi= ne > to leave it in this document for a few iterations for refining the MIB. %sam - nod. >=20 > bfdSessExtTable contains read-create objects but is INDEXed on the BFD > session table rather than AUGMENTing it. As such it needs its own RowStat= us > and StorageType objects. %sam - yes, we missed adding those objects. Will do so in our next version. >=20 > bfdSessExtMapType and bfdSessExtMapPointer should probably get useful DEFV= AL > entries that install an inactive row if the MIB user inadvertantly do a > createAnd* operation. This may suggest that a map type of "none" may be > required. %sam - good catch. We will be make appropriate changes. >=20 > -- Jeff From gregory.mirsky@ericsson.com Thu Jan 12 16:15:54 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5634721F85F1 for ; Thu, 12 Jan 2012 16:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05ySJ3B9y8wb for ; Thu, 12 Jan 2012 16:15:53 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3763F21F854A for ; Thu, 12 Jan 2012 16:15:53 -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 q0D0F9W9022543; Thu, 12 Jan 2012 18:15:51 -0600 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.30]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 12 Jan 2012 19:15:43 -0500 From: Gregory Mirsky To: "Bhatia, Manav (Manav)" , Pablo Frank , Jeffrey Haas Date: Thu, 12 Jan 2012 19:15:41 -0500 Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczQh9js3JVgk8dvSuqjYav/6lT4CwALiQqwADRtJHA= Message-ID: References: <20120109022815.GN7464@slice> <20120109140331.GQ7464@slice> <20120110004503.GS7464@slice> <7C362EEF9C7896468B36C9B79200D8350D028A37A8@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A37A8@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_FE60A4E52763E84B935532D7D9294FF132299CF7CFEUSAACMS0715e_" 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, 13 Jan 2012 00:15:54 -0000 --_000_FE60A4E52763E84B935532D7D9294FF132299CF7CFEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, I wouldn't interpret Pablo's view as "micro BFD sessions using L3 encapsula= tion does not get us anything" but rather as use of L3 addressing vs. L2 ad= dressing doesn't add incremental value to micro-BFD. And the main reason fo= r this conclusion, IMHO, is that IP addresses that might be used by micro-B= FD would not be used by customer's traffic. Hence, we cannot claim that FIB= s are properly set based on state of micro-BFD with L3 addressing. Regards, Greg ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Bhatia, Manav (Manav) Sent: Wednesday, January 11, 2012 3:33 PM To: Pablo Frank; Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: RE: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD= on LAG interfaces)) Hi Pablo, I disagree with your conclusion that micro BFD sessions using L3 encapsulat= ion does not get us anything. Lets look at the two most widely deployed routing protocols, IS-IS and OSPF= . IS-IS packets don't follow the exact data path as the IP packets (since IS-= IS uses L2 encap) and yet once the IS-IS adjacency goes up we trust that we= can use that link for IP forwarding. Even OSPF for that matter does not fo= llow the exact same data path as IP unicast packets since OSPF packets are = multicast (except for DDs which are unicast). In both cases the protocols d= on't follow the same data path as IP unicast and yet we conclude that the I= P routes are reachable based on the information provided by these protocols= . L3 encap micro BFD sessions will tell you that: (1) The link is up (2) The receiver is able to process L3 packets arriving on that link Its imperative that we ensure that each link is able to process L3 packets = since each link [1] will be used for L3 forwarding. And by running BFD on e= ach member link (via micro BFD sessions) we ensure exactly that. And this i= s also precisely the reason why i believe that using multicast encap for mi= cro BFD sessions is nearly as good as using unicast encap. Cheers, Manav [1] The details of how each link gets used is implementation specific and i= ts usually decided based on a hash of certain well known fields from the da= ta packet. ________________________________ From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Pablo Frank Sent: Wednesday, January 11, 2012 11:08 PM To: Jeffrey Haas Cc: rtg-bfd@ietf.org Subject: Re: BFD on LAG requirements (was Re: Multicast vs Unicast (was BFD= on LAG interfaces)) Hi Jeff See PF>> below On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas > wrote: Pablo, On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank wrote: > If the goal is to monitor the L3 forwarding path, then I don't think the > proposed solutions in the draft do that either. Injecting IP unicast or > multicast frames directly into the member links of a LAG does not > necessarily test the L3 datapath because normal packets would be subject = to > the LAG distribution algorithm. And that's kinda the rub. If I want to > ensure that my L3 frames will cross a LAG correctly, I need to have > visibility into the LAG distributor and source frames that will predictab= ly > test the individual legs of the LAG. For IP, this means varying the IP > src/dst and UDP src/dst (how would you do this with the normal IP BFD > encap?). For MPLS sections, I suppose one could vary the entropy label. > Of course, all this assumes that the behaviour of the distributor is kno= wn > and predictable. I'm just not sure how you can write a standard around > this. See other responses for my thoughts on layer 2 BFD. I completely agree with you with regard to layer 3. We fundamentally canno= t exercise the load balancer in a useful way with BFD. I don't think we should try. What we do get out of layer 3 BFD on a per link basis is: - The link is up. - It is able to pass our traffic of interest. PF>> I guess it's the 2nd point that I'm skeptical about. If you are not g= oing through the normal IP forwarding path, what exactly does it prove? If = both sender and receiver are bypassing normal IP stack operation to send an= d receive these frames, it doesn't matter that they're IP encapsulated. Th= ey could be encapsulated in protocol foo and you could achieve the same thi= ng. I guess, fundamentally, unless the L3 BFD is subject to the same forwa= rding rules as other L3 traffic, it doesn't prove anything more than just r= unning BFD directly over L2. Even if you were to assign, say, link-local IP addresses to the individual = links and exchange frames this way then all you're proving is that you can = exchange packets in the link-local subnet. The IP routes that point out th= e LAG interface (as opposed to the individual legs) might still be busted f= or any number of reasons. regards, Pablo --_000_FE60A4E52763E84B935532D7D9294FF132299CF7CFEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Manav,
I wouldn't interpret Pablo's view as "micro BFD se= ssions=20 using L3 encapsulation does not get us anything" but rather as use of L3=20 addressing vs. L2 addressing doesn't add incremental value to micro-BFD. An= d the=20 main reason for this conclusion, IMHO, is that IP addresses that might be u= sed=20 by micro-BFD would not be used by customer's traffic. Hence, we cannot clai= m=20 that FIBs are properly set based on state of micro-BFD with L3=20 addressing.
 
  &n= bsp; Regards,
        Greg

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Bhatia, Manav=20 (Manav)
Sent: Wednesday, January 11, 2012 3:33 PM
To: P= ablo=20 Frank; Jeffrey Haas
Cc: rtg-bfd@ietf.org
Subject: RE: B= FD on=20 LAG requirements (was Re: Multicast vs Unicast (was BFD on LAG=20 interfaces))

Hi Pablo,
 
I disagree with your conclusion that micro BFD ses= sions=20 using L3 encapsulation does not get us anything.
 
Lets look at the two most widely deployed rou= ting=20 protocols, IS-IS and OSPF.
 
IS-IS packets don't follow the exact data path as = the IP=20 packets (since IS-IS uses L2 encap) and yet once the IS-IS adjacency goes u= p we=20 trust that we can use that link for IP forwarding. Even OSPF for that matte= r=20 does not follow the exact same data path as IP unicast packets since OSPF=20 packets are multicast (except for DDs which are unicast). In both cases the= =20 protocols don't follow the same data path as IP unicast and yet we conclude= that=20 the IP routes are reachable based on the information provided by these=20 protocols.
 
L3 encap micro BFD sessions will tell you=20 that:
 
(1) The link is up
(2) The receiver is able to process L3 packets arr= iving on=20 that link
 
Its imperative that we ensure that each link is ab= le to=20 process L3 packets since each link [1] will be used for L3 forwarding. And = by=20 running BFD on each member link (via micro BFD sessions) we ensure exactly = that.=20 And this is also precisely the reason why i believe that using multicast en= cap=20 for micro BFD sessions is nearly as good as using unicast=20 encap.
 
Cheers, Manav
 
[1] The details of how each link gets used is=20 implementation specific and its usually decided based on a hash of certain = well=20 known fields from the data packet.

From: rtg-bfd-bounces@ietf.org=20 [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Pablo=20 Frank
Sent: Wednesday, January 11, 2012 11:08 PM
To: Je= ffrey=20 Haas
Cc: rtg-bfd@ietf.org
Subject: Re: BFD on LAG=20 requirements (was Re: Multicast vs Unicast (was BFD on LAG=20 interfaces))

Hi Jeff=20

See PF>> below

On Mon, Jan 9, 2012 at 7:45 PM, Jeffrey Haas <jhaas@pfrc.org>=20 wrote:
Pablo,

On Mon, Jan 09, 2012 at 11:30:34AM -0500, Pablo Frank= =20 wrote:
> If the goal is to monitor the L3 forwarding path, then I d= on't=20 think the
> proposed solutions in the draft do that either.=20  Injecting IP unicast or
> multicast frames directly into the= =20 member links of a LAG does not
> necessarily test the L3 datapath=20 because normal packets would be subject to
> the LAG distribution=20 algorithm.  And that's kinda the rub.  If I want to
> ens= ure=20 that my L3 frames will cross a LAG correctly, I need to have
>=20 visibility into the LAG distributor and source frames that will=20 predictably
> test the individual legs of the LAG.  For IP, th= is=20 means varying the IP
> src/dst and UDP src/dst (how would you do th= is=20 with the normal IP BFD
> encap?).  For MPLS sections, I suppos= e one=20 could vary the entropy label.
>  Of course, all this assumes t= hat=20 the behaviour of the distributor is known
> and predictable.  = I'm=20 just not sure how you can write a standard around
>=20 this.

See other responses for my thoughts on layer 2=20 BFD.

I completely agree with you with regard to layer 3.  We= =20 fundamentally cannot
exercise the load balancer in a useful way with B= FD.=20  I don't think we
should try.

What we do get out of layer = 3 BFD=20 on a per link basis is:
- The link is up.
- It is able to pass our= =20 traffic of interest.

PF>> I guess it's the 2nd point that I'm skeptical about.  = If=20 you are not going through the normal IP forwarding path, what exactly does = it=20 prove? If both sender and receiver are bypassing normal IP stack operation = to=20 send and receive these frames, it doesn't matter that they're IP encapsulat= ed.=20  They could be encapsulated in protocol foo and you could achieve the = same=20 thing.  I guess, fundamentally, unless the L3 BFD is subject to the sa= me=20 forwarding rules as other L3 traffic, it doesn't prove anything more than j= ust=20 running BFD directly over L2.  

Even if you were to assign, say, link-local IP addresses to the indivi= dual=20 links and exchange frames this way then all you're proving is that you can= =20 exchange packets in the link-local subnet.  The IP routes that point o= ut=20 the LAG interface (as opposed to the individual legs) might still be busted= for=20 any number of reasons.

regards,
Pablo

--_000_FE60A4E52763E84B935532D7D9294FF132299CF7CFEUSAACMS0715e_-- From manav.bhatia@alcatel-lucent.com Thu Jan 12 16:58:38 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4A711E8076 for ; Thu, 12 Jan 2012 16:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 evrCbgQQD838 for ; Thu, 12 Jan 2012 16:58:37 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id ADBAB11E8073 for ; Thu, 12 Jan 2012 16:58:37 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0D0wX9Y009671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 18:58:36 -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 q0D0wWBr006753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Jan 2012 06:28:33 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 13 Jan 2012 06:28:32 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas , "rtg-bfd@ietf.org" Date: Fri, 13 Jan 2012 06:28:32 +0530 Subject: RE: IETF 83 meeting - call for presentations Thread-Topic: IETF 83 meeting - call for presentations Thread-Index: AczRVvhizkbWO57ASRCk5smjxlaKDQANx7tw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20120112181944.GA7464@slice> In-Reply-To: <20120112181944.GA7464@slice> 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: Fri, 13 Jan 2012 00:58:38 -0000 Jeff, I'd like a slot for presenting BFD over LAG members.=20 Will a 10 min slot work? :-) Cheers, Manav -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behalf = Of Jeffrey Haas Sent: Thursday, January 12, 2012 11:50 PM To: rtg-bfd@ietf.org Subject: IETF 83 meeting - call for presentations Given the level of discussion we've had on BFD over LAG members in the mail= ing list, we have an excellent reason to meet at the upcoming IETF 83 in Pa= ris. I have requested a one hour time slot for the working group. This is= a call for presentations for that session. The cutoff for -00 I-Ds is March 5. -- Jeff and Dave From glen.kent@gmail.com Thu Jan 12 17:18:06 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8A11E8096 for ; Thu, 12 Jan 2012 17:18:06 -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 SN06Gf+UviLT for ; Thu, 12 Jan 2012 17:18:06 -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 07FBF11E8099 for ; Thu, 12 Jan 2012 17:18:05 -0800 (PST) Received: by iaae16 with SMTP id e16so3585898iaa.31 for ; Thu, 12 Jan 2012 17:18:05 -0800 (PST) Received-SPF: pass (google.com: domain of glen.kent@gmail.com designates 10.50.15.161 as permitted sender) client-ip=10.50.15.161; Authentication-Results: mr.google.com; spf=pass (google.com: domain of glen.kent@gmail.com designates 10.50.15.161 as permitted sender) smtp.mail=glen.kent@gmail.com; dkim=pass header.i=glen.kent@gmail.com Received: from mr.google.com ([10.50.15.161]) by 10.50.15.161 with SMTP id y1mr11576230igc.4.1326417485692 (num_hops = 1); Thu, 12 Jan 2012 17:18:05 -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=6LiM6F/TXQd9eMlW3v7lU50ztDFW3KJI3+zbKKFiCPQ=; b=FFNXc9B6k+FVNisGcEpiaGRK5jVQZEP65SHMRIo53buWgjwxSE/mhFeu0GAYkQSpw5 Q7iINI4tXNVVEuTyEEyflL2arH4SqiyFxRf7AaJKQnEHo7M0RQjVMkL0jaN2MylZh6xu R8HZqoArM7+7WPwQFblL6KwhaFSR09MpXMFw4= MIME-Version: 1.0 Received: by 10.50.15.161 with SMTP id y1mr9007816igc.4.1326417485620; Thu, 12 Jan 2012 17:18:05 -0800 (PST) Received: by 10.43.44.66 with HTTP; Thu, 12 Jan 2012 17:18:05 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20120112181944.GA7464@slice> <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Fri, 13 Jan 2012 06:48:05 +0530 Message-ID: Subject: Re: IETF 83 meeting - call for presentations From: Glen Kent To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 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, 13 Jan 2012 01:18:06 -0000 Manav, > Will a 10 min slot work? :-) > I think you will need the entire 60 min slot for discussing that draft ! ;-) Glen From jhaas@slice.pfrc.org Thu Jan 12 19:11:33 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A9221F84DD for ; Thu, 12 Jan 2012 19:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.061 X-Spam-Level: X-Spam-Status: No, score=-102.061 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJ2Jz3S5iW03 for ; Thu, 12 Jan 2012 19:11:32 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7A921F84D9 for ; Thu, 12 Jan 2012 19:11:32 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 37E8D224138; Fri, 13 Jan 2012 03:11:31 +0000 (UTC) Date: Thu, 12 Jan 2012 22:11:31 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: IETF 83 meeting - call for presentations Message-ID: <20120113031130.GF7464@slice> References: <20120112181944.GA7464@slice> <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 03:11:33 -0000 On Fri, Jan 13, 2012 at 06:28:32AM +0530, Bhatia, Manav (Manav) wrote: > I'd like a slot for presenting BFD over LAG members. > > Will a 10 min slot work? :-) I figured we'd allocate half an hour to start with. :-) Given that I've had requests for two other time slots on top of this, if we get another I'll need to ask for a longer session. -- Jeff From manav.bhatia@alcatel-lucent.com Thu Jan 12 19:27:07 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9521F855D for ; Thu, 12 Jan 2012 19:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 ANGZKzj-qSXF for ; Thu, 12 Jan 2012 19:27:07 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 65B2021F855A for ; Thu, 12 Jan 2012 19:27:07 -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 q0D3R3Zj003529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 21:27:06 -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 q0D3R2Cg010715 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Jan 2012 08:57:02 +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, 13 Jan 2012 08:57:02 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Date: Fri, 13 Jan 2012 08:57:01 +0530 Subject: RE: IETF 83 meeting - call for presentations Thread-Topic: IETF 83 meeting - call for presentations Thread-Index: AczRoRClYtLalosbTlS3AP6Li+UwTwAAgaBg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0294BD7E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20120112181944.GA7464@slice> <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120113031130.GF7464@slice> In-Reply-To: <20120113031130.GF7464@slice> 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, 13 Jan 2012 03:27:08 -0000 Do you want me to cover the crypto stuff as well? If Yes, then that'll take= another 10-15 mins. Cheers, Manav=20 -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Friday, January 13, 2012 8:42 AM To: Bhatia, Manav (Manav) Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: Re: IETF 83 meeting - call for presentations On Fri, Jan 13, 2012 at 06:28:32AM +0530, Bhatia, Manav (Manav) wrote: > I'd like a slot for presenting BFD over LAG members.=20 >=20 > Will a 10 min slot work? :-) I figured we'd allocate half an hour to start with. :-) Given that I've had requests for two other time slots on top of this, if we= get another I'll need to ask for a longer session. -- Jeff From jhaas@slice.pfrc.org Fri Jan 13 07:20:34 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA6F21F8545 for ; Fri, 13 Jan 2012 07:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck4DsAAk86DR for ; Fri, 13 Jan 2012 07:20:34 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 370C221F84AF for ; Fri, 13 Jan 2012 07:20:34 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id D9E0222415F; Fri, 13 Jan 2012 15:20:33 +0000 (UTC) Date: Fri, 13 Jan 2012 10:20:33 -0500 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: IETF 83 meeting - call for presentations Message-ID: <20120113152033.GH7464@slice> References: <20120112181944.GA7464@slice> <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120113031130.GF7464@slice> <7C362EEF9C7896468B36C9B79200D8350D0294BD7E@INBANSXCHMBSA1.in.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0294BD7E@INBANSXCHMBSA1.in.alcatel-lucent.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "rtg-bfd@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 15:20:34 -0000 [Part of the commentary below is meant to be general to the WG. Please don't take it personally, Manav. :-)] On Fri, Jan 13, 2012 at 08:57:01AM +0530, Bhatia, Manav (Manav) wrote: > Do you want me to cover the crypto stuff as well? If Yes, then that'll take another 10-15 mins. Are there any changes of real note since the last presentation? Is there anything contentious requiring discussion? If not, would you consider instead preparing slides prior to the session covering the update and sharing them with the list? I'd post them on the datatracker. The above questions are prompted to some extent by a recent plenary where we discussed how to effectively use meeting time. If we can spend the bulk of our time on presenting new proposals and reserving meeting time for discussion, I think we all benefit more. I'd love to move minor status update material out of session. If you think we'd benefit from the presentation, I'll allocate a slot. -- Jeff From manav.bhatia@alcatel-lucent.com Fri Jan 13 08:26:51 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8F21F8503 for ; Fri, 13 Jan 2012 08:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 BlIIXrLKSBFZ for ; Fri, 13 Jan 2012 08:26:51 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4B47621F84FB for ; Fri, 13 Jan 2012 08:26:51 -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 q0DGQlBC018956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jan 2012 10:26:49 -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 q0DGQf5B031760 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 13 Jan 2012 21:56:46 +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, 13 Jan 2012 21:56:41 +0530 From: "Bhatia, Manav (Manav)" To: Jeffrey Haas Date: Fri, 13 Jan 2012 21:56:41 +0530 Subject: RE: IETF 83 meeting - call for presentations Thread-Topic: IETF 83 meeting - call for presentations Thread-Index: AczSBuiGporjtTieTuGArRodURMuAgAB87cg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0294BF7C@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <20120112181944.GA7464@slice> <7C362EEF9C7896468B36C9B79200D8350D0294BD6D@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120113031130.GF7464@slice> <7C362EEF9C7896468B36C9B79200D8350D0294BD7E@INBANSXCHMBSA1.in.alcatel-lucent.com> <20120113152033.GH7464@slice> In-Reply-To: <20120113152033.GH7464@slice> 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: Fri, 13 Jan 2012 16:26:52 -0000 I completely understand where youre coming from since I was in Taipei when = this was being discussed in one the meetings. I really don't see anything contentious or significant that warrants a f2f = discussion which is why I asked you if you wanted me to present the two BFD= security drafts. We have done similar security work for the other routing = protocols and the two drafts that I had in mind for discussion just extend = similar mechanisms for BFD.=20 So, no need for a slot. Cheers, Manav -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org]=20 Sent: Friday, January 13, 2012 8:51 PM To: Bhatia, Manav (Manav) Cc: Jeffrey Haas; rtg-bfd@ietf.org Subject: Re: IETF 83 meeting - call for presentations [Part of the commentary below is meant to be general to the WG. Please don= 't take it personally, Manav. :-)] On Fri, Jan 13, 2012 at 08:57:01AM +0530, Bhatia, Manav (Manav) wrote: > Do you want me to cover the crypto stuff as well? If Yes, then that'll ta= ke another 10-15 mins. Are there any changes of real note since the last presentation? =20 Is there anything contentious requiring discussion? If not, would you consider instead preparing slides prior to the session co= vering the update and sharing them with the list? I'd post them on the dat= atracker. The above questions are prompted to some extent by a recent plenary where w= e discussed how to effectively use meeting time. If we can spend the bulk = of our time on presenting new proposals and reserving meeting time for disc= ussion, I think we all benefit more. I'd love to move minor status update = material out of session. =20 If you think we'd benefit from the presentation, I'll allocate a slot. -- Jeff From toms.sanders@gmail.com Fri Jan 20 17:05:30 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BEC21F856F for ; Fri, 20 Jan 2012 17:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 Op5RbwQ5xsOb for ; Fri, 20 Jan 2012 17:05:29 -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 8693F21F855A for ; Fri, 20 Jan 2012 17:05:29 -0800 (PST) Received: by wibhn9 with SMTP id hn9so1105998wib.31 for ; Fri, 20 Jan 2012 17:05:28 -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=29eQJgkKSZ5vvxyuJDpVmF/fW5meHsc+djZIOSpKiwo=; b=b5ddrWrNB/AtgEz1tIwsaI+HTwZtt1eDyofPHCvc+DT88f9oeLHp29Emio2JjBlrO8 9olRZ++jrmr6DIqhb/DMJh8aW95vSKiKiua8zokx9rjqcIw0PGIiBPPBzPIhRcjsP5ag K7aO+5yEtfYAXTf5ibWyKnW/o+qIlYj3OZsNU= MIME-Version: 1.0 Received: by 10.180.82.5 with SMTP id e5mr1028480wiy.18.1327107928779; Fri, 20 Jan 2012 17:05:28 -0800 (PST) Received: by 10.223.123.142 with HTTP; Fri, 20 Jan 2012 17:05:28 -0800 (PST) Date: Sat, 21 Jan 2012 06:35:28 +0530 Message-ID: Subject: Status now? (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) From: Tom Sanders To: "rtg-bfd@ietf.org" Content-Type: text/plain; charset=UTF-8 Cc: David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 01:05:30 -0000 So where are we with the discussion of BFD over LAGs? Did we reach any conclusion on the layer that the "micro BFD sessions" should operate in? Is there any update on whether the "micro BFD sessions" need to use unicast or multicast addressing? Are the authors of draft-mmm-* coming up with a new version that captures some progress? We have also not heard what the WG chairs feel about the whole discussion. It would be instructive to hear their take on this as well. Toms From manav.bhatia@alcatel-lucent.com Fri Jan 20 20:04:45 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4A211E8083 for ; Fri, 20 Jan 2012 20:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 LRNO3cx5nWqX for ; Fri, 20 Jan 2012 20:04:44 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8687711E8074 for ; Fri, 20 Jan 2012 20:04:43 -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 q0L44cc1008797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2012 22:04:40 -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 q0L42KdP007688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 21 Jan 2012 09:34:35 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sat, 21 Jan 2012 09:33:18 +0530 From: "Bhatia, Manav (Manav)" To: Tom Sanders , "rtg-bfd@ietf.org" Date: Sat, 21 Jan 2012 09:33:15 +0530 Subject: RE: Status now? (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: Status now? (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczX2MjqkUAlIbSsQ8GELlakYZk2aQAGEWHQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D0294CC35@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 Cc: David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 04:04:45 -0000 Hi Toms, We're collaborating with a few people on the next revision of draft-mmm-bfd= -on-lags. You will see it posted some time very soon. Cheers, Manav=20 > -----Original Message----- > From: Tom Sanders [mailto:toms.sanders@gmail.com]=20 > Sent: Saturday, January 21, 2012 6:35 AM > To: rtg-bfd@ietf.org > Cc: Bhatia, Manav (Manav); Marc Binderberger; Jeffrey Haas; David Ward > Subject: Status now? (was Re: Multicast vs Unicast (was BFD=20 > on LAG interfaces)) >=20 > So where are we with the discussion of BFD over LAGs? >=20 > Did we reach any conclusion on the layer that the "micro BFD sessions" > should operate in? Is there any update on whether the "micro=20 > BFD sessions" need to use unicast or multicast addressing?=20 > Are the authors of draft-mmm-* coming up with a new version=20 > that captures some progress? >=20 > We have also not heard what the WG chairs feel about the=20 > whole discussion. It would be instructive to hear their take=20 > on this as well. >=20 > Toms > = From Alexander.Vainshtein@ecitele.com Sat Jan 21 03:24:24 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3F321F8555 for ; Sat, 21 Jan 2012 03:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[AWL=0.668, 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 APE9zncfdFDy for ; Sat, 21 Jan 2012 03:24:22 -0800 (PST) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 16E2E21F8552 for ; Sat, 21 Jan 2012 03:24:21 -0800 (PST) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-174.messagelabs.com!1327145058!10030067!1 X-Originating-IP: [147.234.242.234] X-StarScan-Version: 6.4.3; banners=-,-,- Received: (qmail 22036 invoked from network); 21 Jan 2012 11:24:19 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-3.tower-174.messagelabs.com with SMTP; 21 Jan 2012 11:24:19 -0000 X-AuditID: 93eaf2e7-b7f2a6d000000e7d-66-4f1aaccc36d6 Received: from ilptexch01.ecitele.com ( [172.31.244.40]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 66.D4.03709.CCCAA1F4; Sat, 21 Jan 2012 14:17:16 +0200 (IST) Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Sat, 21 Jan 2012 13:24:18 +0200 From: Alexander Vainshtein To: Tom Sanders Date: Sat, 21 Jan 2012 13:20:44 +0200 Subject: RE: Status now? (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Topic: Status now? (was Re: Multicast vs Unicast (was BFD on LAG interfaces)) Thread-Index: AczX2LDglgGmXfiPRSu08n+1J+T9vAAVh7vu Message-ID: 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-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA1VTa0gUURjtzuxuozkxrdpeN6lpsohS282CjVyJoLIi1qiE6kdNu7fdod3Z YWYUlSKxQJKITIvaII189DBKC3tKpkEoaUX5ioyWXmQFomY+KpvZMbN/537nnO98d+a7BG4M GswEx8tI5FkvYwjXFfX0DSQ8qTI7LENFUbb664PA1v+zFtja+i5hq/DU4tFqfeqdQPfU1LKy YSwN35ELklme98usjGgXkpx2Jk3kMllnNkNzLjtjZWjByzqRD/GynWEFAfEuJiU8WSlyPI14 p9/F8W47s36LI8FmW74iwcqkLJhnTVoZvtXDSTRK8LGcl/YhSWLdiFYq6qy8C7novX6Rlj2I FncX4Z7h9iGdUBqWdbLtLZ4LqqYWgDACUstgsP+6TsMz4bM31wwFIJwwUnUAXqzsAtqhGMAT jzuBqjJQdlhzpdug4ihqIbzaW4CpGKfWwRddL0NYR82Hpx4MKF0JIpLaBhvK12rydDj6rVen 4aWwuqMDUyUktRkeag91N1JpcKg4LyQJU8o/vl8I1YEy24/mqvEkE3z1vgTTZqZg2f2nuIaj 4ed3v/WaPhq+zr8GNH08LL3XZ9DwYlhx/ktIT1IzYNOZ9+N3j4EPL3bqjgNTYFJEYJI9MMke mGQvBbrLIJrzCvIen9tiTUROTkZelOj0+2qAtiyfboORkrgGQBGAiSBhc4zDqGczpWxfA4gh MCaaPFZidhin7/G7sj2s5NklZniR1AAggTNRZGaBIiddbHYOEv1/KZvyjQtx8zSnX/3V8q4k i+W/A2MiPzi/bjJSbmXn9iEkIPGvNZYgGEhGliqJM0TkRll7Oa/8j8aIMDU5Qkl+qU5FSgLr kzi3xjeDuWYTWa8SlEp4MvgJr/oyDo6NjfUAk3LPSPKWqopQdnHC3aM0xpTGBB9qrLyHCcqc C+oOHE4sF/Qtm1K6ks52HIktiT8Iq4XNa4hga23rarpl3g0wQmfWN34MFi4YbFxSObtpcNbI 7sTV+6kg1Ve+5HQ+9nyK9dmcuCt8axsnlc/c6cB23E3Pirx5tNcdfxrDb2+ImnZA/2vjI8s2 MWdpXc+5irbm0afLg3l6rHV7auN3Rid5WOsiXJTYP8c8ITH0AwAA Cc: "rtg-bfd@ietf.org" , David Ward X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 11:24:24 -0000 Toms hi, It has been my understanding that the discussion around this draft have resu= lted in the WG chairs requesting a slot for a F2F session at the Paris IETF= - for the first time in several years. I would take it as an indication (of a kind) of how they feel about the whol= e discussion. Dave, Hope I do not presume too much. My 2c, Sasha. ________________________________________ From: rtg-bfd-bounces@ietf.org [rtg-bfd-bounces@ietf.org] On Behalf Of Tom S= anders [toms.sanders@gmail.com] Sent: Saturday, January 21, 2012 3:05 AM To: rtg-bfd@ietf.org Cc: David Ward Subject: Status now? (was Re: Multicast vs Unicast (was BFD on LAG interface= s)) So where are we with the discussion of BFD over LAGs? Did we reach any conclusion on the layer that the "micro BFD sessions" should operate in? Is there any update on whether the "micro BFD sessions" need to use unicast or multicast addressing? Are the authors of draft-mmm-* coming up with a new version that captures some progress? We have also not heard what the WG chairs feel about the whole discussion. It would be instructive to hear their take on this as well. Toms 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 sam.aldrin@gmail.com Mon Jan 23 22:06:59 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E5121F855D for ; Mon, 23 Jan 2012 22:06:59 -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 Ik+Mik7q13UY for ; Mon, 23 Jan 2012 22:06:58 -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 133F321F8552 for ; Mon, 23 Jan 2012 22:06:57 -0800 (PST) Received: by ghbg16 with SMTP id g16so1304364ghb.31 for ; Mon, 23 Jan 2012 22:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=d5wGNsaFs6+pMYk7jyiSpNJyo9ULVjVIlXHzpxHOO5w=; b=uD7DpiDSj++idJ4KAvbOJVl7AdQTJFhMKlFf0r5MU4/Qts8iU7+lMvfPMYXMUrbJpp rUFgncfnkoxe2dvjs5dVCHLpSPYKponnTBOho1d+uV+X+8QEcLgu9IlH6No7RjGooN3v 7KWPJvKIUQjTT7hNgfwu86m1P2pcvTBxukvVk= Received: by 10.236.184.196 with SMTP id s44mr16170636yhm.9.1327385217707; Mon, 23 Jan 2012 22:06:57 -0800 (PST) Received: from [192.168.1.5] (c-107-3-156-34.hsd1.ca.comcast.net. [107.3.156.34]) by mx.google.com with ESMTPS id u39sm15917731yhe.5.2012.01.23.22.06.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jan 2012 22:06:56 -0800 (PST) Subject: Re: BFD MIB extension for MPLS-TP Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Sam Aldrin In-Reply-To: <20120108235123.GL7464@slice> Date: Mon, 23 Jan 2012 22:06:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <877A7275-7115-4E2F-882B-F2722D7FB68F@gmail.com> References: <20120108235123.GL7464@slice> To: Jeffrey Haas X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Tue, 24 Jan 2012 10:14:32 -0800 Cc: draft-vkst-bfd-mpls-mib@tools.ietf.org, Ross Callon , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:06:59 -0000 [apologies for the delayed reply] Hi Ross, George and Loa, As Jeff has eluded to in the email, the MIB work for TP could all be = within MPLS WG, even though the extensions are being done to support = other areas like BFD.=20 The draft was intentionally published within BFD WG as the extension is = being done, in order to support MPLS including TP extensions, for the = existing BFD MIB. When I presented at Taipei, the question was asked by = AD that the adoption should be taken up within BFD WG, as draft belongs = to BFD WG. If I have to ask for WG adoption within MPLS WG, I need to move the = draft to MPLS. I do not have any personal preference on where it should = belong, as long as it gets adopted and we could proceed to finish the = work. So, could you please give us the guidance on how to proceed further? We = are ready with new version of the draft, which we would like to submit = ASAP. Thanks in advance -sam On Jan 8, 2012, at 3:51 PM, Jeffrey Haas wrote: > [cc: mpls chairs] >=20 > Sam, >=20 > I believe this MIB is in scope for the BFD WG charter: >=20 > "1. Develop the MIB module for BFD and submit it to the IESG for = publication > as a Proposed Standard.=20 >=20 > 5. Assist in the standardization of the BFD protocol for MPLS-TP. The > preferred solution will be interoperable with the current BFD > specification." >=20 > However, there's also some argument to keep all of the MPLS-TP MIB = work > together in the MPLS WG. >=20 > Most of the MPLS-TP work, including MIBs, is occurring in the MPLS WG. > Doing a cursory review of the two other drafts you presented in the = same > session, there is no strong binding from the oam-id or te-mib to the = BFD > MPLS-TP MIB, but the MPLS-TP BFD MIB has a strong dependency on the = oam-id > MIB. The MPLS-TP BFD MIB depends on a common index from the bfd = session > table. Given these dependencies, it seems to make some some sense to = keep > the MPLS-TP MIB work bundled together in on group. >=20 > I was not at IETF 82. Per the MPLS WG minutes it sounds like there is > some debate as to which WG would cover this work. I personally have = no > strong preference as to which group is in the draft name since the BFD = WG > will be providing review, per charter, regardless of which group it is = in. >=20 > With that, I pass the WG adoption token back to the MPLS chairs. = We're > happy to take on the work if you don't want it. >=20 > -- Jeff >=20 > On Thu, Dec 15, 2011 at 08:17:24PM -0800, Sam Aldrin wrote: >> Hello BFD WG, >>=20 >>=20 >> We have submitted a new draft, BFD MIB extensions to support MPLS-TP, = prior >> to IETF82 at Taipei. >>=20 >> The draft is located at >> http://datatracker.ietf.org/doc/draft-vkst-bfd-mpls-mib/ >>=20 >>=20 >> We have presented the draft in MPLS WG to get feedback from that WG. >>=20 >> As there was no WG session at Taipei, we are seeking feedback from = BFD WG >> over the mailing list. >>=20 >>=20 >> 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. >>=20 >>=20 >> Appreciate your time. >>=20 >>=20 >> cheers >>=20 >> -sam From manav.bhatia@alcatel-lucent.com Wed Jan 25 03:41:10 2012 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB53421F8653 for ; Wed, 25 Jan 2012 03:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.632 X-Spam-Level: X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 J+QT0aITzeVF for ; Wed, 25 Jan 2012 03:41:10 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1418421F8652 for ; Wed, 25 Jan 2012 03:41:09 -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 q0PBf6HR016203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jan 2012 05:41:09 -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 q0PBf6NR001300 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 25 Jan 2012 17:11:06 +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, 25 Jan 2012 17:11:06 +0530 From: "Bhatia, Manav (Manav)" To: "rtg-bfd@ietf.org" Date: Wed, 25 Jan 2012 17:11:05 +0530 Subject: FW: BFD Gap Analysis Thread-Topic: BFD Gap Analysis Thread-Index: AczbVUXPhtGMc9+DTDGIZwAjGBAgbwAABfCw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D029FDC8F@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.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: Wed, 25 Jan 2012 11:41:10 -0000 This is the -02 version. The -01 version in fact had all the changes that c= ame out of the review done in BFD mailing list. Difference between this and the -00 version. http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-bhatia= -zhang-karp-bfd-analysis-00.txt&url2=3Dhttp://tools.ietf.org/id/draft-bhati= a-zhang-karp-bfd-analysis-02.txt It should btw be noted that replay concerns pointed out in this document ha= ve been addressed in draft-ietf-bfd-generic-crypto-auth-00. Cheers, Manav -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Bha= tia, Manav (Manav) Sent: Wednesday, January 25, 2012 5:04 PM To: karp@ietf.org Subject: [karp] BFD Gap Analysis Hi, Many many moons ago Dacheng and I had written a short draft doing BFD gap a= nalysis as part of the KARP Phase 1. The draft was briefly discussed in the= BFD WG and this version incorporates the comments we received there + some= boiler plate changes. http://tools.ietf.org/id/draft-bhatia-zhang-karp-bfd-analysis-02.txt Comments on this version are welcome! Cheers, Manav _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp