From dai.xuehui@zte.com.cn Thu May 6 23:20:41 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3A93A6883; Thu, 6 May 2010 23:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.813 X-Spam-Level: X-Spam-Status: No, score=-93.813 tagged_above=-999 required=5 tests=[AWL=-4.507, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTYeDYy2W6ks; Thu, 6 May 2010 23:20:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 381733A68C3; Thu, 6 May 2010 23:20:21 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 36887813339890; Fri, 7 May 2010 14:15:16 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 6793.3729454058; Fri, 7 May 2010 14:20:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o476JSxw054381; Fri, 7 May 2010 14:19:33 +0800 (CST) (envelope-from dai.xuehui@zte.com.cn) In-Reply-To: To: kireeti@juniper.net, mpls@ietf.org, rahul@juniper.net, "rtg-bfd@ietf.org" , swallow@cisco.com Subject: =?GB2312?B?tPC4tDogZG91YnQgYWJvdXQgIklQIFJvdXRlciBBbGVydCBPcHRpb24iIA==?= =?GB2312?B?YmV0d2VlbiBNUExTLUJGRCAmIExTUC1QaW5n?= MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: dai.xuehui@zte.com.cn Date: Fri, 7 May 2010 14:16:54 +0800 X-MIMETrack: S/MIME Sign by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-07 14:20:01, Serialize by Notes Client on DaiXueHui078045/user/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-07 14:20:01, Serialize complete at 2010-05-07 14:20:01, S/MIME Sign failed at 2010-05-07 14:20:01: =?GB2312?B?1dKyu7W9seDC68Pc1L8=?=, Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-05-07 14:19:25, Serialize complete at 2010-05-07 14:19:25 Content-Type: multipart/alternative; boundary="=_alternative 0022CAF44825771C_=" X-MAIL: mse2.zte.com.cn o476JSxw054381 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 07 May 2010 06:20:41 -0000 This is a multipart message in MIME format. --=_alternative 0022CAF44825771C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpDYW4gc29tZW9uZSBoZWxwIG1lIG9uIHRoaXMgcXVlc3Rpb24/DQoNCkJlc3Qg UmVnYXJkcy4NCg0KDQoNCg0KtPrRqbvhMDc4MDQ1L3VzZXIvenRlX2x0ZCANCjIwMTAtMDQtMjgg MTY6NDgNCg0KytW8/sjLDQpyYWh1bEBqdW5pcGVyLm5ldCwga2lyZWV0aUBqdW5pcGVyLm5ldCwg c3dhbGxvd0BjaXNjby5jb20NCrOty80NCm1wbHNAaWV0Zi5vcmcsICJydGctYmZkQGlldGYub3Jn IiA8cnRnLWJmZEBpZXRmLm9yZz4NCtb3zOINCmRvdWJ0IGFib3V0ICJJUCBSb3V0ZXIgQWxlcnQg T3B0aW9uIiBiZXR3ZWVuIE1QTFMtQkZEICYgTFNQLVBpbmcNCg0KDQoNCg0KDQpIaSBhbGwsDQoN CkluIFJGQzQzNzksIFNlY3Rpb24gNC4zIC0gIlNlbmRpbmcgYW4gTVBMUyBFY2hvIFJlcXVlc3Qi LCBUaGUgUm91dGVyIEFsZXJ0IA0Kb3B0aW9uIE1VU1QgYmUgc2V0IGluIHRoZSBJUCBoZWFkZXIu DQoNCkluIGRyYWZ0LWlldGYtYmZkLW1wbHMtMDcsIHNlY3Rpb24tNyAiRW5jYXBzdWxhdGlvbiIs IEkgY2FuICpOT1QqIGZpbmQgDQphbnl0aGluZyBhYm91dCAidGhlIFJvdXRlciBBbGVydCBPcHRp b24iLg0KDQpJTU8sIHRoZSBNUExTLUJGRCByZWZlciB0byBSRkM0Mzc5OyB3aHkgYXJlIHRoZXkg ICpOT1QqIHRoZSBzYW1lIG9uIHRoZSANCm9wZXJhdGlvbiBvZiAiUm91dGVyIEFsZXJ0IE9wdGlv biI/DQoNCg0KQlIuDQpYdWVodWkNCg0KDQo= --=_alternative 0022CAF44825771C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zPkNhbiBzb21lb25lIGhlbHAgbWUgb24gdGhpcyBxdWVzdGlvbj88 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgUmVn YXJkcy48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM0JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+tPrRqbvhMDc4MDQ1L3VzZXIvenRlX2x0ZDwvYj4NCjwvZm9udD4NCjxwPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA0LTI4IDE2OjQ4PC9mb250Pg0KPHRkIHdp ZHRoPTY1JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnJhaHVsQGp1bmlwZXIu bmV0LCBraXJlZXRpQGp1bmlwZXIubmV0LA0Kc3dhbGxvd0BjaXNjby5jb208L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPm1wbHNAaWV0Zi5vcmcsICZxdW90O3J0Zy1iZmRAaWV0Zi5vcmcmcXVvdDsNCiZsdDty dGctYmZkQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ZG91YnQgYWJvdXQgJnF1b3Q7 SVAgUm91dGVyIEFsZXJ0IE9wdGlvbiZxdW90Ow0KYmV0d2VlbiBNUExTLUJGRCAmYW1wOyBMU1At UGluZzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJAy87M5SI+SGkgYWxsLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQMvO zOUiPkluIFJGQzQzNzksIFNlY3Rpb24gNC4zIC0gJnF1b3Q7U2VuZGluZw0KYW4gTVBMUyBFY2hv IFJlcXVlc3QmcXVvdDssIFRoZSBSb3V0ZXIgQWxlcnQgb3B0aW9uIDwvZm9udD48Zm9udCBzaXpl PTMgY29sb3I9cmVkIGZhY2U9IkDLzszlIj5NVVNUPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJA y87M5SI+DQpiZSBzZXQgaW4gdGhlIElQIGhlYWRlci48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9IkDLzszlIj5JbiBkcmFmdC1pZXRmLWJmZC1tcGxzLTA3LCBzZWN0aW9uLTcg JnF1b3Q7RW5jYXBzdWxhdGlvbiZxdW90OywNCkkgY2FuICpOT1QqIGZpbmQgYW55dGhpbmcgYWJv dXQgJnF1b3Q7dGhlIFJvdXRlciBBbGVydCBPcHRpb24mcXVvdDsuPGJyPg0KPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJAy87M5SI+SU1PLCB0aGUgTVBMUy1CRkQgcmVmZXIgdG8gUkZD NDM3OTsgd2h5DQphcmUgdGhleSAmbmJzcDsqTk9UKiB0aGUgc2FtZSBvbiB0aGUgb3BlcmF0aW9u IG9mICZxdW90O1JvdXRlciBBbGVydCBPcHRpb24mcXVvdDs/PC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CUi48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlh1ZWh1aTxicj4NCjwvZm9udD4NCjxicj4NCg== --=_alternative 0022CAF44825771C_=-- From lavanya.srivatsa@aricent.com Thu May 27 00:24:56 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30613A68D8 for ; Thu, 27 May 2010 00:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmWQfHNtsabU for ; Thu, 27 May 2010 00:24:48 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 35A843A6964 for ; Thu, 27 May 2010 00:24:17 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 0B2F336B67 for ; Thu, 27 May 2010 12:49:37 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id E92EA36B57 for ; Thu, 27 May 2010 12:49:36 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 27 May 2010 12:54:01 +0530 From: Lavanya Srivatsa To: rtg-bfd Date: Thu, 27 May 2010 12:54:00 +0530 Subject: Status of draft-ietf-bfd-mpls-07?? Thread-Topic: Status of draft-ietf-bfd-mpls-07?? Thread-Index: Acr9bZPez7HZlRK5T8aSaLEoe8lj0w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AF085525D89CCA4EB233BE7E5BF2FDAB1693C8FD6FGUREXMB02ASIA_" MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 27 May 2010 07:24:56 -0000 --_000_AF085525D89CCA4EB233BE7E5BF2FDAB1693C8FD6FGUREXMB02ASIA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello BFD Chairs, Any idea on when the "BFD for MPLS" draft will clear the RFC Editor's queue= to become an RFC? The reason I am asking this is because this seems to hav= e expired in December 2008 and no newer version has been updated. The Base BFD draft on the other hand is also in the RFC Editor's queue but = it still seems to be active (expiring in July 2010). - Lavanya --_000_AF085525D89CCA4EB233BE7E5BF2FDAB1693C8FD6FGUREXMB02ASIA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello BFD Chairs,

 

Any idea on when the “BFD for MPLS” draft will clear the RFC Editor’s queue to become an RFC?= The reason I am asking this is because this seems to have expired in December 2= 008 and no newer version has been updated.

The Base BFD draft on the other hand is also in the RFC Editor’s queue but it still seems to be active (expir= ing in July 2010).

 

- Lavanya

--_000_AF085525D89CCA4EB233BE7E5BF2FDAB1693C8FD6FGUREXMB02ASIA_-- From jhaas@slice.pfrc.org Thu May 27 06:19:05 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6FA73A6A36 for ; Thu, 27 May 2010 06:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOcg2JL1zRKx for ; Thu, 27 May 2010 06:19:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id C01993A68C3 for ; Thu, 27 May 2010 06:19:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 81E67224169; Thu, 27 May 2010 13:18:55 +0000 (UTC) Date: Thu, 27 May 2010 13:18:55 +0000 From: Jeffrey Haas To: Lavanya Srivatsa Subject: Re: Status of draft-ietf-bfd-mpls-07?? Message-ID: <20100527131855.GB5512@slice> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rtg-bfd X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 27 May 2010 13:19:05 -0000 Lavanya, On Thu, May 27, 2010 at 12:54:00PM +0530, Lavanya Srivatsa wrote: > Any idea on when the "BFD for MPLS" draft will clear the RFC Editor's queue to become an RFC? The reason I am asking this is because this seems to have expired in December 2008 and no newer version has been updated. > The Base BFD draft on the other hand is also in the RFC Editor's queue but it still seems to be active (expiring in July 2010). The bfd-mpls document, along with the other BFD documents, are currently in the final stages of RFC publication. The last editorial nits are being resolved. Once all of the documents are considered finished, they will be published in one large block. -- Jeff From mukund.mani@gmail.com Sun May 30 12:04:31 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA183A68CE for ; Sun, 30 May 2010 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1ttMWBfCKlU for ; Sun, 30 May 2010 12:04:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 6C1483A6855 for ; Sun, 30 May 2010 12:04:30 -0700 (PDT) Received: by vws3 with SMTP id 3so894197vws.31 for ; Sun, 30 May 2010 12:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=WaS2FytvS0ep6kt3rjbsO/FvzfKdrtj80ornCfvw41w=; b=XfN8FJt2BbEFqTtfYY+jqCHeeC0Ta6txzYk4Y0r9sWTWvKrjSH6/pfXjJOCGM2wWx5 3afeAIGyD8dFRiwnUpMc7LKwOP+rUebLe2TRY3fMLf0aGvbWzOFYmGWa3V7M9iVpovDu 6+Zkm1v9nqMRAGuyUgP6HQBnii0IzVsSPtm7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TLFgCjkUR3aDPI6UCd8YHjaQ5ivSFNaQHjxbYyMj0pWfuiH2ZB/L+VppAZEvHMsD1K wrmmbVqsdQZt7J/HS5ihzs6GRTFjkqEMb3wYArVkuw0wztmk6TL41o+H7Iedbxx4i2zB HAVsdsEEOT0j+WsD663C/s2Ch/zbyFxhoVQ7c= MIME-Version: 1.0 Received: by 10.224.118.75 with SMTP id u11mr1237899qaq.261.1275246256506; Sun, 30 May 2010 12:04:16 -0700 (PDT) Received: by 10.229.73.206 with HTTP; Sun, 30 May 2010 12:04:16 -0700 (PDT) Date: Mon, 31 May 2010 00:34:16 +0530 Message-ID: Subject: Query on draft-chen-mpls-bfd-enhancement-01 From: Mukund Mani To: rtg-bfd@ietf.org Content-Type: multipart/alternative; boundary=000feae9a9be1ec8360487d4682d X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 30 May 2010 19:04:31 -0000 --000feae9a9be1ec8360487d4682d Content-Type: text/plain; charset=ISO-8859-1 Hi Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft authors kindly clarify the same: Section 4 on session establishment mentions the following: If node with the larger IP receives LSP ping message signaling BFD session with Session Control TLV, LSP ping reply must be transmitted with "Backward direction BFD session exists" to the ingress LSR. In the case of BFD session provisioned on both nodes in the Active mode, the LSP Ping for the backward direction BFD session could be received even when the forward direction session is not yet established. In that case is it correct to mention that the "Backward direction BFD session exists" as return code? Kindly let me know if I am missing something here... With Regards Mukund --000feae9a9be1ec8360487d4682d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

Have a query w.r.t "draft-chen-mpls-bfd-enhancem= ent-01". Could the draft authors kindly clarify the same:
Section 4 on session establishment mentions the following: 

If node with the larger IP receives LSP pi=
ng
message signaling BFD session with Session Control TLV, LSP ping
reply must be transmitted with "Backward direction BFD session
exists" to the ingress LSR.
 =A0
In the=
 case of BFD session provisioned on both nodes in the Active mode, the LSP =
Ping for the backward direction BFD session could be received even when=A0<=
/span>the forward direction session is n=
ot yet established. In that case is it correct to mention that the "Ba=
ckward direction BFD session exists" as return code?



Kindly let me know if I am missing something here...





With Regards


Mukund
--000feae9a9be1ec8360487d4682d-- From glen.kent@gmail.com Sun May 30 21:12:26 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC43E3A69B4 for ; Sun, 30 May 2010 21:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NV08PCxDmzM for ; Sun, 30 May 2010 21:12:25 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id A739B3A698F for ; Sun, 30 May 2010 21:12:25 -0700 (PDT) Received: by gwj19 with SMTP id 19so2505092gwj.31 for ; Sun, 30 May 2010 21:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=p8XK+kEnTWgtvVf1O6tYhJkjTHigl9CTJG8Z/Mgx5o0=; b=bk3ONv4Bkei50NGwKzG09WacLQULEsXfOmZOABItgCCqjmgP6WcjxXKMT8uCATu5f6 HQRvI/nPOSKz7ePSlYzWB0haMb4LmjsPvvxziIgNGu6GOasumA5Z4uPJcAi1Rq7GTfEB EQ9NHGXZyuDrPBBZjRUU2N8QUziei02MTZStc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=t1XVO6rUNt2vGvVT3XPDFtJbGlkzipbdwtcmY5RfrsLrbtUeT9LQWgL9kHJh+4S9ce LpLMDI0pdiKdbOy5LQkoeTK/9ZcBh2oUZRRDEwKTpcJeJr+AGYnzG7EE6tIsyo1reogP DAAGuaNA4qBWy9JJ+vCPFQbpWFB0fCuhy64Ig= MIME-Version: 1.0 Received: by 10.101.204.38 with SMTP id g38mr4128638anq.223.1275279131553; Sun, 30 May 2010 21:12:11 -0700 (PDT) Received: by 10.100.248.18 with HTTP; Sun, 30 May 2010 21:12:11 -0700 (PDT) Date: Mon, 31 May 2010 09:42:11 +0530 Message-ID: Subject: BFD alternate path? From: Glen Kent To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 31 May 2010 04:12:26 -0000 Hi, Assume the link that i have between two BFD enabled routers A and B goes down. Will BFD, since its riding on top of UDP, automatically follow the routing table and try to find an alternate path to keep the connectivity alive? If Yes, then this will result in BFD session remaining up, while the link is down. Is this acceptable? Glen From vishwas.ietf@gmail.com Sun May 30 21:20:44 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E563A6925 for ; Sun, 30 May 2010 21:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlAJuyxuksib for ; Sun, 30 May 2010 21:20:41 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 7C2F23A6842 for ; Sun, 30 May 2010 21:20:41 -0700 (PDT) Received: by yxn35 with SMTP id 35so401308yxn.31 for ; Sun, 30 May 2010 21:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zqXyKcUCPbBkosAarHRJpigemlMhcmM0S7ujFVlv9YU=; b=jCqDbpy62DxrHdTr6K8sCWNKEN/MkInwPvM68232FdV6l9WwhtJX56h4pm+rrImaAh tvNwBhujippeb8MYjS1BOTh9yaRnFJEmtHt/Nlwc0bQujIFEjbTQzPza11Fi2yR7AhXy vxMHP/71x8m8njyIe58T3GYt5ERNG2zXe5sVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=b7agSzhsWv7ukvyG775wxZi5K6rkQQ4fccSOj8tsDbF5S+mUFRnW9qcx9Z3hS1BSvc nP2v2axkHqnNYmXpP1Tswhg2SgFoSnMcYLsWJrW4sIYoqrqaeuxNDqZptBR+ER4s55oo hz26iRA3ty+0jVAcn/8FaD1oeFXF3HAp7X6pI= MIME-Version: 1.0 Received: by 10.150.210.16 with SMTP id i16mr4902629ybg.70.1275279627311; Sun, 30 May 2010 21:20:27 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Sun, 30 May 2010 21:20:27 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 May 2010 21:20:27 -0700 Message-ID: Subject: Re: BFD alternate path? From: Vishwas Manral To: Glen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 31 May 2010 04:20:44 -0000 Hi Glen, You are nearly right. The case however is just the opposite. In most cases however the Route table calculation will be triggered by topology changes which will be triggered by BFD. However in some cases (multihop sessions), the BFD session timers will be set to higher value so that the lower level sessions can converge faster (which will result in the session staying up). If we do not want the behavior we can set the timers to smaller values. This however is a choice of the operator. Thanks, Vishwas On Sun, May 30, 2010 at 9:12 PM, Glen Kent wrote: > Hi, > > Assume the link that i have between two BFD enabled routers A and B > goes down. Will BFD, since its riding on top of UDP, automatically > follow the routing table and try to find an alternate path to keep the > connectivity alive? > > If Yes, then this will result in BFD session remaining up, while the > link is down. Is this acceptable? > > Glen > From vishwas.ietf@gmail.com Sun May 30 23:27:00 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65603A69E8 for ; Sun, 30 May 2010 23:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VopThvb+XiCr for ; Sun, 30 May 2010 23:27:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B703E3A69DD for ; Sun, 30 May 2010 23:26:59 -0700 (PDT) Received: by gyh4 with SMTP id 4so2562571gyh.31 for ; Sun, 30 May 2010 23:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dAvmwz7IEGRwKeFEPi1OY5mqI6zLnvFtDUJX46T2A1Q=; b=TpJsQn/GzIQigdz/luGMD9XL4kukRBC3h2VSdwKo3dsR54t0kBdAWkqcVrqTHY/Jgf U+oGzYAfOi9Y2eoHxSfOsmULLQO/hJEvuQhXRV/P4oKpEbhiW2zFDdEtQiBT3YVwbZcF SPQAMSZrSri3O25toObK2SKerd5SQlZ3v6IFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QKufEcsi+Jvg4G+7+3bPA4xn1ooQAuSwipLYE/8tt6xrfGMPkUNgFYI7AU30bTLw2h +Fsx33AoVlNsZBJkUGQ6m5+/GsWN93XoF66ldjdBvIcgra2Wme2D/KzA9q3Wmsk/3JHS B3cmuiTnuGMFzXr/wvawPhIY36Ub+iMdfYJtE= MIME-Version: 1.0 Received: by 10.150.210.9 with SMTP id i9mr4605565ybg.434.1275287205275; Sun, 30 May 2010 23:26:45 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Sun, 30 May 2010 23:26:45 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 May 2010 23:26:45 -0700 Message-ID: Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 From: Vishwas Manral To: Mukund Mani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 31 May 2010 06:27:00 -0000 Hi Mukund, The version-02 of the draft has been out since March. You may want to look at that. It does not have the text you have mentioned. Thanks, Vishwas On Sun, May 30, 2010 at 12:04 PM, Mukund Mani wrote= : > Hi > Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft > authors kindly clarify the same: > Section 4 on session establishment mentions the following: > > If node with the larger IP receives LSP ping > message signaling BFD session with Session Control TLV, LSP ping > reply must be transmitted with "Backward direction BFD session > exists" to the ingress LSR. > > > > In the case of BFD session provisioned on both nodes in the Active mode, = the > LSP Ping for the backward direction BFD session could be received even > when=A0the forward direction session is not yet established. In that case= is > it correct to mention that the "Backward direction BFD session exists" as > return code? > > Kindly let me know if I am missing something here... > > With Regards > > Mukund From vishwas.ietf@gmail.com Sun May 30 23:36:15 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35623A69F5 for ; Sun, 30 May 2010 23:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hduohpj9-HCV for ; Sun, 30 May 2010 23:35:54 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 3AAB43A69EE for ; Sun, 30 May 2010 23:34:55 -0700 (PDT) Received: by gwj19 with SMTP id 19so2561043gwj.31 for ; Sun, 30 May 2010 23:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QI3Hy4EGJjjVTU5XWLvSpYg38WNw1pRIYfR67JoHOJg=; b=C9zD2ORudh7fzrG7Z1x7J/QolugZTS8XDrjknij9b+SV18S5NDajfiz4B1CVD/vjsp exwGtcWjNSAflkYXuwMqFurhGVxrmlswt7PhuklV6gadz/shiI+aGMcjDe7GENey/D1T fcPKNjWraiblKeGk1hjXTt9kmahjfctziBJw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NR2QewcStPfsanfttDahkfoPxBgrlM1QD5tjgI+iWy82WvBfxZIw0yUgoFOI5WkCSn aF0vuWhadsKAuG/T1dFYZdvj3DAPHkpzs6adQl2rY0lT3q6lsSwUXUAYjQwqEEempOPc F7zPwcUodAS7y5wdJdxYgI5pkRQnFnKta4RrQ= MIME-Version: 1.0 Received: by 10.150.244.11 with SMTP id r11mr4668250ybh.366.1275287673473; Sun, 30 May 2010 23:34:33 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Sun, 30 May 2010 23:34:33 -0700 (PDT) In-Reply-To: References: Date: Sun, 30 May 2010 23:34:33 -0700 Message-ID: Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 From: Vishwas Manral To: Mukund Mani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 31 May 2010 06:36:15 -0000 Hi Mukund, I am sorry I just realized I was looking at the wrong draft. Yes, an return code you mentioned could be sent back. Thanks, Vishwas On Sun, May 30, 2010 at 12:04 PM, Mukund Mani wrote= : > Hi > Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft > authors kindly clarify the same: > Section 4 on session establishment mentions the following: > > If node with the larger IP receives LSP ping > message signaling BFD session with Session Control TLV, LSP ping > reply must be transmitted with "Backward direction BFD session > exists" to the ingress LSR. > > > > In the case of BFD session provisioned on both nodes in the Active mode, = the > LSP Ping for the backward direction BFD session could be received even > when=A0the forward direction session is not yet established. In that case= is > it correct to mention that the "Backward direction BFD session exists" as > return code? > > Kindly let me know if I am missing something here... > > With Regards > > Mukund From glen.kent@gmail.com Mon May 31 15:56:54 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337D33A6A5E for ; Mon, 31 May 2010 15:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWCPme3N4WmC for ; Mon, 31 May 2010 15:56:53 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 1E4FE3A680D for ; Mon, 31 May 2010 15:56:53 -0700 (PDT) Received: by gwj19 with SMTP id 19so3204598gwj.31 for ; Mon, 31 May 2010 15:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bTtYNYKdZFj1aoTvm7b/MllGHEIAOkHPHp/YplPHJa0=; b=Aul4odBferxo2f25NC5y/fa8XUIM9bJq6zlCFkdd3/iVqCveR7h1WlARy+xw0NVpwg ICRId6Z+eF8mqLGreMrhC3gIQooZWttUxk/qqo57VyveuO5S22WDQFEfonv305y3pMIx SBzVr2YZsxWY/Gqo/mg+7d2iq3IaiR3GH5zCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U65crHhyADcd9+iD/C0Bso+wiv7V9AX9a7ooVObfZPdRugDoc9U7awMLT/Z/TaJbw4 axAH2vsviCGkqHSLbSTjUzlVMtf+u54RL4APXMVoOxoQeNUM4HRZy8XNOfm0n+/ca/Sr 7GXYIU56nD/0JGydt41PPwPiyKGmAK49GVr5Y= MIME-Version: 1.0 Received: by 10.100.234.26 with SMTP id g26mr5579723anh.244.1275346596110; Mon, 31 May 2010 15:56:36 -0700 (PDT) Received: by 10.100.248.18 with HTTP; Mon, 31 May 2010 15:56:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 04:26:36 +0530 Message-ID: Subject: Re: BFD alternate path? From: Glen Kent To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 31 May 2010 22:56:54 -0000 > > However in some cases (multihop sessions), the BFD session timers will > be set to higher value so that the lower level sessions can converge In case of multihop sessions, say between two IBGP peers, what is a lower level session here? Is this the IGP? My doubt is this: A -- B | | C ---+ A and B are directly connected. A can also reach B via C. I am running a BFD session between A and B. Since A and B are directly connected, BFD packets will always use the A-B interface. However, if A-B fails, then will BFD packets take the alternate path available via C to reach the other end. I am not sure if this will happen as its a chicken-and-egg problem - BFD can take the alternate path only if the IGP recomputes the path. IGP can recompute only when it learns that A-B has gone down, and its most probably only BFD that can inform the IGP that A-B has gone down (assume for instance when there is a switch in between A and B and the switch goes down). Also, what will happen if there is a default route on both A and B via C. In that case BFD need not wait for the IGP to reconverge. It can always take the alternate path. Will in such cases, BFD take the alternate path and keep the session alive? If it does that then its wrong as the physical link has indeed gone down. Glen > faster (which will result in the session staying up). If we do not > want the behavior we can set the timers to smaller values. This > however is a choice of the operator. > > Thanks, > Vishwas > > On Sun, May 30, 2010 at 9:12 PM, Glen Kent wrote: >> Hi, >> >> Assume the link that i have between two BFD enabled routers A and B >> goes down. Will BFD, since its riding on top of UDP, automatically >> follow the routing table and try to find an alternate path to keep the >> connectivity alive? >> >> If Yes, then this will result in BFD session remaining up, while the >> link is down. Is this acceptable? >> >> Glen >> > From vishwas.ietf@gmail.com Mon May 31 16:28:40 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65C33A6912 for ; Mon, 31 May 2010 16:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1ThmwdeEsSG for ; Mon, 31 May 2010 16:28:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 92A7C3A68A7 for ; Mon, 31 May 2010 16:28:39 -0700 (PDT) Received: by yxn35 with SMTP id 35so531528yxn.31 for ; Mon, 31 May 2010 16:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g2pbZfUiG6ejmgsgPsgnTR4jFp0aWT6AhgMv292Lhtc=; b=FbOpTTcuvsaKvSC5gABSs1ys725q6tLIhCks7OnmLnauheRFVlCHkKtKKHG5n1Xmis tmn+McVS4eaSDufGn3gA4w86fzx1ssDzOocuCTFRQHLMo4H1uoKgIpHIQf8nRyNeEUUy H/ECuaTMycvjPVVIQ+IoW/hnhktAfHMQYpBj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VuOufFGCDBKeS9HNJ2kum92LNA723+918bAyzBUN0OTYUXynBHBU/yinNteSnDafOs D2A+mIS+10zJV2CgCd4vOOfTlX92vYfQy1LFCVdixU4vWqq/m9mwFy58dhm/uQK0ISlS 7qxIs/vH4vaAPBYOO15dZrQhPaMLfcN9KwU4o= MIME-Version: 1.0 Received: by 10.150.251.10 with SMTP id y10mr6061346ybh.123.1275348505145; Mon, 31 May 2010 16:28:25 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Mon, 31 May 2010 16:28:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 May 2010 16:28:25 -0700 Message-ID: Subject: Re: BFD alternate path? From: Vishwas Manral To: Glen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 31 May 2010 23:28:40 -0000 Hi Glen, If you want to monitor that a session goes over a particular link you can impose the restriction to a Multihop session in which case the BFD session will fail. If we do not impose the restriction the session will stay UP. I do not see any sort of collision of interests. It depends on what an operator wants and can get the right behavior using BFD. Thanks, Vishwas On Mon, May 31, 2010 at 3:56 PM, Glen Kent wrote: >> >> However in some cases (multihop sessions), the BFD session timers will >> be set to higher value so that the lower level sessions can converge > > In case of multihop sessions, say between two IBGP =A0peers, what is a > lower level session here? Is this the IGP? > > My doubt is this: > > A -- B > | =A0 =A0 =A0| > C ---+ > > A and B are directly connected. A can also reach B via C. I am running > a BFD session between A and B. Since A and B are directly connected, > BFD packets will always use the A-B interface. However, if A-B fails, > then will BFD packets take the alternate path available via C to reach > the other end. I am not sure if this will happen as its a > chicken-and-egg problem - BFD can take the alternate path only if the > IGP recomputes the path. IGP can recompute only when it learns that > A-B has gone down, and its most probably only BFD that can inform the > IGP that A-B has gone down (assume for instance when there is a switch > in between A and B and the switch goes down). > > Also, what will happen if there is a default route on both A and B via > C. In that case BFD need not wait for the IGP to reconverge. It can > always take the alternate path. Will in such cases, BFD take the > alternate path and keep the session alive? If it does that then its > wrong as the physical link has indeed gone down. > > Glen > >> faster (which will result in the session staying up). If we do not >> want the behavior we can set the timers to smaller values. This >> however is a choice of the operator. >> >> Thanks, >> Vishwas >> >> On Sun, May 30, 2010 at 9:12 PM, Glen Kent wrote: >>> Hi, >>> >>> Assume the link that i have between two BFD enabled routers A and B >>> goes down. Will BFD, since its riding on top of UDP, automatically >>> follow the routing table and try to find an alternate path to keep the >>> connectivity alive? >>> >>> If Yes, then this will result in BFD session remaining up, while the >>> link is down. Is this acceptable? >>> >>> Glen >>> >> > From glen.kent@gmail.com Mon May 31 17:13:46 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B133A6921 for ; Mon, 31 May 2010 17:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1hHQ7JLKUeM for ; Mon, 31 May 2010 17:13:44 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 55F183A6891 for ; Mon, 31 May 2010 17:13:44 -0700 (PDT) Received: by gyh4 with SMTP id 4so3245831gyh.31 for ; Mon, 31 May 2010 17:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Ih8mVDRWdUzIZIohBH1ZVpnDmPYEGlAs7FVnB86ioho=; b=P9nvPJeNyy7RtRTl9D/e0smvQxDUubbw2B2Qna+HZt4Ue1ayZ50D/3m3H3fUxLjMT8 bpFsxkMTPlBmA6A33/eAyt602Mi+cmfawJ4JxTc3SIoMGevhMLy3QuKyIOzprXPkunqf bFgSQXQr7b84GbS9Rqcm+OUdYPrQd4I3XzN4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rfiAO3QUYXIiVsbhnCUmbX3C4Xl/NQ8ztW1Mh7JXesETwoTrCOH4scF3WPfVWjp0Xr sncY7YSrF+wZtmrk8eAuDTdjzJOh+iudSr3/Ge672qngox+gtu9jyP7+apMk2HJzSh2e AYs/syJ5uMah9tzUmf7YzTtwLwYxmg85aHNYU= MIME-Version: 1.0 Received: by 10.101.141.27 with SMTP id t27mr5519734ann.246.1275351209534; Mon, 31 May 2010 17:13:29 -0700 (PDT) Received: by 10.100.248.18 with HTTP; Mon, 31 May 2010 17:13:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 05:43:29 +0530 Message-ID: Subject: Re: BFD alternate path? From: Glen Kent To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 00:13:46 -0000 Vishwas, This might work for a multihop session. How about directly connected next-hops that i brought up in my previous email. A -- B | | C ---+ In this case if link A-B fails, will BFD on A and B use the alternate path via C (assume its the default gateway in for both A and B)? More details in my previous email. Glen On Tue, Jun 1, 2010 at 4:58 AM, Vishwas Manral wro= te: > Hi Glen, > > If you want to monitor that a session goes over a particular link you > can impose the restriction to a Multihop session in which case the BFD > session will fail. > > If we do not impose the restriction the session will stay UP. I do not > see any sort of collision of interests. It depends on what an operator > wants and can get the right behavior using BFD. > > Thanks, > Vishwas > > On Mon, May 31, 2010 at 3:56 PM, Glen Kent wrote: >>> >>> However in some cases (multihop sessions), the BFD session timers will >>> be set to higher value so that the lower level sessions can converge >> >> In case of multihop sessions, say between two IBGP =A0peers, what is a >> lower level session here? Is this the IGP? >> >> My doubt is this: >> >> A -- B >> | =A0 =A0 =A0| >> C ---+ >> >> A and B are directly connected. A can also reach B via C. I am running >> a BFD session between A and B. Since A and B are directly connected, >> BFD packets will always use the A-B interface. However, if A-B fails, >> then will BFD packets take the alternate path available via C to reach >> the other end. I am not sure if this will happen as its a >> chicken-and-egg problem - BFD can take the alternate path only if the >> IGP recomputes the path. IGP can recompute only when it learns that >> A-B has gone down, and its most probably only BFD that can inform the >> IGP that A-B has gone down (assume for instance when there is a switch >> in between A and B and the switch goes down). >> >> Also, what will happen if there is a default route on both A and B via >> C. In that case BFD need not wait for the IGP to reconverge. It can >> always take the alternate path. Will in such cases, BFD take the >> alternate path and keep the session alive? If it does that then its >> wrong as the physical link has indeed gone down. >> >> Glen >> >>> faster (which will result in the session staying up). If we do not >>> want the behavior we can set the timers to smaller values. This >>> however is a choice of the operator. >>> >>> Thanks, >>> Vishwas >>> >>> On Sun, May 30, 2010 at 9:12 PM, Glen Kent wrote: >>>> Hi, >>>> >>>> Assume the link that i have between two BFD enabled routers A and B >>>> goes down. Will BFD, since its riding on top of UDP, automatically >>>> follow the routing table and try to find an alternate path to keep the >>>> connectivity alive? >>>> >>>> If Yes, then this will result in BFD session remaining up, while the >>>> link is down. Is this acceptable? >>>> >>>> Glen >>>> >>> >> > From vishwas.ietf@gmail.com Mon May 31 18:39:42 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66183A685B for ; Mon, 31 May 2010 18:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.757 X-Spam-Level: X-Spam-Status: No, score=-0.757 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0gaVcx3avOk for ; Mon, 31 May 2010 18:39:41 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id ACF643A67AC for ; Mon, 31 May 2010 18:39:41 -0700 (PDT) Received: by gyh4 with SMTP id 4so3295543gyh.31 for ; Mon, 31 May 2010 18:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dec4IVZRP5v0VmEO+NRqHoK1kF8dl4Fv2mlvym4SwbY=; b=UcXCGPNjgPZqzOF3tsfOlT/ThupNWQ9oCV0tGFgDq2bHcLld8fQnSTnwhjtkudHH/u 3q2NdX0XB/tWXdQtrmkdncsquhoE7tl1eOvAvIfhs3CK8cEMEooD0Zdv3GvnAPCj+Dh4 pO1WnX+XKJTVK6kg+A/npuHa32aVghQ9QxVx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IMXS2goYEbRqatP1nJF+BiR1ue9mc/V1tJSol/G8SijF5XXnio+TNL1iBJGznCylO2 g0Hghf5PiGyfb8d70g+Bq3501qTLd+T+RaDXAT3u97w2QbtNLBpxhXTItzMraxtzit8M WWCzzetZgbUpTfu0GMgDvOg6MMUWdCwTS2oHI= MIME-Version: 1.0 Received: by 10.151.88.8 with SMTP id q8mr6129541ybl.67.1275356367176; Mon, 31 May 2010 18:39:27 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Mon, 31 May 2010 18:39:27 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 May 2010 18:39:27 -0700 Message-ID: Subject: Re: BFD alternate path? From: Vishwas Manral To: Glen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 01:39:42 -0000 Hi Glen, In single hop cases the BFD session is generally bound to the interface. So the BFD session will brought down. Thanks, Vishwas On Mon, May 31, 2010 at 5:13 PM, Glen Kent wrote: > Vishwas, > > This might work for a multihop session. How about directly connected > next-hops that i brought up in my previous email. > > A -- B > | =A0 =A0 =A0| > C ---+ > > In this case if link A-B fails, will BFD on A and B use the alternate > path via C (assume its the default gateway in for both A and B)? More > details in my previous email. > > Glen > > On Tue, Jun 1, 2010 at 4:58 AM, Vishwas Manral w= rote: >> Hi Glen, >> >> If you want to monitor that a session goes over a particular link you >> can impose the restriction to a Multihop session in which case the BFD >> session will fail. >> >> If we do not impose the restriction the session will stay UP. I do not >> see any sort of collision of interests. It depends on what an operator >> wants and can get the right behavior using BFD. >> >> Thanks, >> Vishwas >> >> On Mon, May 31, 2010 at 3:56 PM, Glen Kent wrote: >>>> >>>> However in some cases (multihop sessions), the BFD session timers will >>>> be set to higher value so that the lower level sessions can converge >>> >>> In case of multihop sessions, say between two IBGP =A0peers, what is a >>> lower level session here? Is this the IGP? >>> >>> My doubt is this: >>> >>> A -- B >>> | =A0 =A0 =A0| >>> C ---+ >>> >>> A and B are directly connected. A can also reach B via C. I am running >>> a BFD session between A and B. Since A and B are directly connected, >>> BFD packets will always use the A-B interface. However, if A-B fails, >>> then will BFD packets take the alternate path available via C to reach >>> the other end. I am not sure if this will happen as its a >>> chicken-and-egg problem - BFD can take the alternate path only if the >>> IGP recomputes the path. IGP can recompute only when it learns that >>> A-B has gone down, and its most probably only BFD that can inform the >>> IGP that A-B has gone down (assume for instance when there is a switch >>> in between A and B and the switch goes down). >>> >>> Also, what will happen if there is a default route on both A and B via >>> C. In that case BFD need not wait for the IGP to reconverge. It can >>> always take the alternate path. Will in such cases, BFD take the >>> alternate path and keep the session alive? If it does that then its >>> wrong as the physical link has indeed gone down. >>> >>> Glen >>> >>>> faster (which will result in the session staying up). If we do not >>>> want the behavior we can set the timers to smaller values. This >>>> however is a choice of the operator. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Sun, May 30, 2010 at 9:12 PM, Glen Kent wrote= : >>>>> Hi, >>>>> >>>>> Assume the link that i have between two BFD enabled routers A and B >>>>> goes down. Will BFD, since its riding on top of UDP, automatically >>>>> follow the routing table and try to find an alternate path to keep th= e >>>>> connectivity alive? >>>>> >>>>> If Yes, then this will result in BFD session remaining up, while the >>>>> link is down. Is this acceptable? >>>>> >>>>> Glen >>>>> >>>> >>> >> > From glen.kent@gmail.com Mon May 31 20:01:12 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE7B3A686D for ; Mon, 31 May 2010 20:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hur9+WpY9U1 for ; Mon, 31 May 2010 20:01:11 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id B47FC3A6403 for ; Mon, 31 May 2010 20:01:11 -0700 (PDT) Received: by gwj19 with SMTP id 19so3342558gwj.31 for ; Mon, 31 May 2010 20:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4pr684CIZqlBzk8EeOy8ON5Tb11KRGs2IQPoOcKRFuk=; b=GUvZ/2J5fc5ak9bqeblY/lHmcVhTLrzgNvGHAyPNm5CXhWYougZsmud+5ADQwShgf7 u9dUSY4ArWTeILmhK3O5ty07ZGKDIZHCVrOo0KCJaa/eINAXwPdGpafqzznjV5HIrU7G 0QlXS9dPxTWfKdEhoXWDqUSe18u8Nr3Q44Vpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bKjsAf0evXWoIqBBdT4rR9J/zF4Oi1cClpzZgxzHqm+3oFXMHnKjXXWg9VFYfjzy81 GxyIH6FSJ9kzGE0jgOnUFpp5IsWrWwtbV1lGT7SWXRRm+DXp+hDT414lmQB14SoCzYxw 3M3RMeLbT61+Ql+ICngsF6gm2IfseWtG7wRX4= MIME-Version: 1.0 Received: by 10.101.29.24 with SMTP id g24mr5753628anj.263.1275361257200; Mon, 31 May 2010 20:00:57 -0700 (PDT) Received: by 10.100.248.18 with HTTP; Mon, 31 May 2010 20:00:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 08:30:57 +0530 Message-ID: Subject: Re: BFD alternate path? From: Glen Kent To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 03:01:13 -0000 Hi Vishwas, Dont intend to be picky, but .. > > In single hop cases the BFD session is generally bound to the > interface. So the BFD session will brought down. You use "generally". Does it mean that there would be instances when the BFD session for a directly connected nexthop will NOT be tied to an interface. If so, when and under what circumstances would that happen? Glen > > Thanks, > Vishwas > > On Mon, May 31, 2010 at 5:13 PM, Glen Kent wrote: >> Vishwas, >> >> This might work for a multihop session. How about directly connected >> next-hops that i brought up in my previous email. >> >> A -- B >> | =A0 =A0 =A0| >> C ---+ >> >> In this case if link A-B fails, will BFD on A and B use the alternate >> path via C (assume its the default gateway in for both A and B)? More >> details in my previous email. >> >> Glen >> >> On Tue, Jun 1, 2010 at 4:58 AM, Vishwas Manral = wrote: >>> Hi Glen, >>> >>> If you want to monitor that a session goes over a particular link you >>> can impose the restriction to a Multihop session in which case the BFD >>> session will fail. >>> >>> If we do not impose the restriction the session will stay UP. I do not >>> see any sort of collision of interests. It depends on what an operator >>> wants and can get the right behavior using BFD. >>> >>> Thanks, >>> Vishwas >>> >>> On Mon, May 31, 2010 at 3:56 PM, Glen Kent wrote: >>>>> >>>>> However in some cases (multihop sessions), the BFD session timers wil= l >>>>> be set to higher value so that the lower level sessions can converge >>>> >>>> In case of multihop sessions, say between two IBGP =A0peers, what is a >>>> lower level session here? Is this the IGP? >>>> >>>> My doubt is this: >>>> >>>> A -- B >>>> | =A0 =A0 =A0| >>>> C ---+ >>>> >>>> A and B are directly connected. A can also reach B via C. I am running >>>> a BFD session between A and B. Since A and B are directly connected, >>>> BFD packets will always use the A-B interface. However, if A-B fails, >>>> then will BFD packets take the alternate path available via C to reach >>>> the other end. I am not sure if this will happen as its a >>>> chicken-and-egg problem - BFD can take the alternate path only if the >>>> IGP recomputes the path. IGP can recompute only when it learns that >>>> A-B has gone down, and its most probably only BFD that can inform the >>>> IGP that A-B has gone down (assume for instance when there is a switch >>>> in between A and B and the switch goes down). >>>> >>>> Also, what will happen if there is a default route on both A and B via >>>> C. In that case BFD need not wait for the IGP to reconverge. It can >>>> always take the alternate path. Will in such cases, BFD take the >>>> alternate path and keep the session alive? If it does that then its >>>> wrong as the physical link has indeed gone down. >>>> >>>> Glen >>>> >>>>> faster (which will result in the session staying up). If we do not >>>>> want the behavior we can set the timers to smaller values. This >>>>> however is a choice of the operator. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Sun, May 30, 2010 at 9:12 PM, Glen Kent wrot= e: >>>>>> Hi, >>>>>> >>>>>> Assume the link that i have between two BFD enabled routers A and B >>>>>> goes down. Will BFD, since its riding on top of UDP, automatically >>>>>> follow the routing table and try to find an alternate path to keep t= he >>>>>> connectivity alive? >>>>>> >>>>>> If Yes, then this will result in BFD session remaining up, while the >>>>>> link is down. Is this acceptable? >>>>>> >>>>>> Glen >>>>>> >>>>> >>>> >>> >> > From vishwas.ietf@gmail.com Mon May 31 20:24:51 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07CF3A6915 for ; Mon, 31 May 2010 20:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4oObxjOGhZC for ; Mon, 31 May 2010 20:24:50 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D16D83A68A9 for ; Mon, 31 May 2010 20:24:49 -0700 (PDT) Received: by gwj19 with SMTP id 19so3355102gwj.31 for ; Mon, 31 May 2010 20:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DJtjEOxjcU9A39HUMjrPudLLi526+fe90/q+6UrzcEw=; b=oFcLmp9PSsvMLAU6hN0Z4aS1T9VGAa4KkHW+4w7TILagubus1C/DyS5Q2bMH5vXfGk 4UBA3FuElniFeHscIuIhToW4qm5xRixWOIiWXxn2AqXzOexJ+Pz5n93krEGgEhS0/4wS /ff++Jt/lhxgK7zWNpGJEpLnXPu62q/wBrgIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BvxQTCeEnWXQARqR0MI5Zy0CsFiYGnMDocTCE1n1ZzYd4JzvFT7DDOc65G6G5OP3pp yjZiahfGUnwjTzu9N4t7sJCHg7rrIDHvsqJ3mZq64301d+To2Sp9MkN/ZzXt3Ec5SQM/ LjOEbPrFl77BCWLSbyWGdze0MXSR0MhuvFGy8= MIME-Version: 1.0 Received: by 10.150.14.5 with SMTP id 5mr5831254ybn.17.1275362674634; Mon, 31 May 2010 20:24:34 -0700 (PDT) Received: by 10.150.95.5 with HTTP; Mon, 31 May 2010 20:24:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 May 2010 20:24:34 -0700 Message-ID: Subject: Re: BFD alternate path? From: Vishwas Manral To: Glen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 03:24:51 -0000 Hi Glen, If I wanted to monitor if the peer was UP and not just an interface UP I could use that. One example I can give you is in LMP, we can have multiple control channels over individual interfaces for a control adjacency for a neighbor. So if the peer crashed I would want to bring down the control adjacency, but if an interface went down I would want to keep the control adjacency UP. One way could be have a different BFD session over each control channel. Another way is to have a control channel which is not bound to an interface. So in case there is another way the rerouting can happen even before BFD can trigger it (loss of carrier), we can use a single BFD session to the peer router. Hope that is of some help. Thanks, Vishwas On Mon, May 31, 2010 at 8:00 PM, Glen Kent wrote: > Hi Vishwas, > > Dont intend to be picky, but .. > >> >> In single hop cases the BFD session is generally bound to the >> interface. So the BFD session will brought down. > > You use "generally". Does it mean that there would be instances when > the BFD session for a directly connected nexthop will NOT be tied to > an interface. If so, when and under what circumstances would that > happen? > > Glen > >> >> Thanks, >> Vishwas >> >> On Mon, May 31, 2010 at 5:13 PM, Glen Kent wrote: >>> Vishwas, >>> >>> This might work for a multihop session. How about directly connected >>> next-hops that i brought up in my previous email. >>> >>> A -- B >>> | =A0 =A0 =A0| >>> C ---+ >>> >>> In this case if link A-B fails, will BFD on A and B use the alternate >>> path via C (assume its the default gateway in for both A and B)? More >>> details in my previous email. >>> >>> Glen >>> >>> On Tue, Jun 1, 2010 at 4:58 AM, Vishwas Manral = wrote: >>>> Hi Glen, >>>> >>>> If you want to monitor that a session goes over a particular link you >>>> can impose the restriction to a Multihop session in which case the BFD >>>> session will fail. >>>> >>>> If we do not impose the restriction the session will stay UP. I do not >>>> see any sort of collision of interests. It depends on what an operator >>>> wants and can get the right behavior using BFD. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Mon, May 31, 2010 at 3:56 PM, Glen Kent wrote= : >>>>>> >>>>>> However in some cases (multihop sessions), the BFD session timers wi= ll >>>>>> be set to higher value so that the lower level sessions can converge >>>>> >>>>> In case of multihop sessions, say between two IBGP =A0peers, what is = a >>>>> lower level session here? Is this the IGP? >>>>> >>>>> My doubt is this: >>>>> >>>>> A -- B >>>>> | =A0 =A0 =A0| >>>>> C ---+ >>>>> >>>>> A and B are directly connected. A can also reach B via C. I am runnin= g >>>>> a BFD session between A and B. Since A and B are directly connected, >>>>> BFD packets will always use the A-B interface. However, if A-B fails, >>>>> then will BFD packets take the alternate path available via C to reac= h >>>>> the other end. I am not sure if this will happen as its a >>>>> chicken-and-egg problem - BFD can take the alternate path only if the >>>>> IGP recomputes the path. IGP can recompute only when it learns that >>>>> A-B has gone down, and its most probably only BFD that can inform the >>>>> IGP that A-B has gone down (assume for instance when there is a switc= h >>>>> in between A and B and the switch goes down). >>>>> >>>>> Also, what will happen if there is a default route on both A and B vi= a >>>>> C. In that case BFD need not wait for the IGP to reconverge. It can >>>>> always take the alternate path. Will in such cases, BFD take the >>>>> alternate path and keep the session alive? If it does that then its >>>>> wrong as the physical link has indeed gone down. >>>>> >>>>> Glen >>>>> >>>>>> faster (which will result in the session staying up). If we do not >>>>>> want the behavior we can set the timers to smaller values. This >>>>>> however is a choice of the operator. >>>>>> >>>>>> Thanks, >>>>>> Vishwas >>>>>> >>>>>> On Sun, May 30, 2010 at 9:12 PM, Glen Kent wro= te: >>>>>>> Hi, >>>>>>> >>>>>>> Assume the link that i have between two BFD enabled routers A and B >>>>>>> goes down. Will BFD, since its riding on top of UDP, automatically >>>>>>> follow the routing table and try to find an alternate path to keep = the >>>>>>> connectivity alive? >>>>>>> >>>>>>> If Yes, then this will result in BFD session remaining up, while th= e >>>>>>> link is down. Is this acceptable? >>>>>>> >>>>>>> Glen >>>>>>> >>>>>> >>>>> >>>> >>> >> >