From apvelan@cisco.com Thu Jul 16 03:12:23 2009 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 2583A28C158 for ; Thu, 16 Jul 2009 03:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 Q99rZ4Rl-J6H for ; Thu, 16 Jul 2009 03:12:17 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id A23F33A6931 for ; Thu, 16 Jul 2009 03:12:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAyaXkpAaMF0/2dsb2JhbACCKCy0fIgjkRkFhAuBRQ X-IronPort-AV: E=Sophos;i="4.42,410,1243814400"; d="scan'208,217";a="58152464" Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 16 Jul 2009 10:12:47 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6GACjnx029195; Thu, 16 Jul 2009 20:12:46 +1000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6GACOvJ020480; Thu, 16 Jul 2009 10:12:45 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 15:42:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA05FD.F639AFED" Subject: Re: draft-palanivelan-bfd-v2-gr-02 Date: Thu, 16 Jul 2009 15:42:44 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: draft-palanivelan-bfd-v2-gr-02 Thread-Index: AcoF9WgkEb/cwgT2RDibfG313JcnwgACG0Ow From: "Palanivelan A (apvelan)" To: , X-OriginalArrivalTime: 16 Jul 2009 10:12:45.0206 (UTC) FILETIME=[F6637B60:01CA05FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15546; t=1247739167; x=1248603167; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=apvelan@cisco.com; z=From:=20=22Palanivelan=20A=20(apvelan)=22=20 |Subject:=20Re=3A=20draft-palanivelan-bfd-v2-gr-02 |Sender:=20; bh=k7OprXnNAmK5h9Ib3LcaHsVyZGqaTi+mR56xoVt7ByY=; b=CyqPIX8yjy3k1RoJTG1zaEOOUN2dK/JJR47q7PPGUMxGobBVBMib7PoIxU LM9GOJkZMVp9XzGjrVHv7KZKlVBRLQaNKlBFHIAbCzw8DzzbTIbfVegnxHQh +5HISaddR/YQ1jez3imAg97UCl7Fmd5nVILnpR04e55/o9SRHK/zM=; Authentication-Results: syd-dkim-1; header.From=apvelan@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); 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, 16 Jul 2009 10:12:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA05FD.F639AFED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nitin, It is very true that BFD works well in planned restarts and we don't need GR extensions there. But, we have seen issues when bfd is working along with other time intensive, high priority events. =20 In such a scenario, for GR, we are likely to hit bfd timer expiry which will be treated as a failure, thus bringing down the adjacencies (ISIS/OSPF). One such example is when there are scaled number of PPPoE sessions on a SP router that also has bfd enabled (with strict timers). =20 This would mean looking for a workaround at the architecture level of your router to make this work. =20 In fact, this sort of experience let me into writing this draft. Do revert back for more discussion. PS: sorry for that late reply. I had a recent road accident that put me off for a longer time. Regards, A.Palanivelan To: >, > * Subject: Re: draft-palanivelan-bfd-v2-gr-01 * From: Nitin Bahadur > * Date: Tue, 3 Feb 2009 16:49:12 -0800 * Delivered-to: rtg-bfd at core3.amsl.com =20 * List-archive: * List-help: * List-id: "RTG Area: Bidirectional Forwarding Detection DT" * List-post: * List-subscribe: , * List-unsubscribe: , * Thread-index: AcmGYmVThhxLBgEuTGCCrADrG/c6fQ=3D=3D * Thread-topic: Re: draft-palanivelan-bfd-v2-gr-01 ________________________________ Hi, =20 You really do not need GR extensions to BFD to help with planned restart. There is enough text in draft-ietf-bfd-generic=20 (Section 4.3.2.2) to help you accomplish what you want. =20 At the top of my head, I can think of 2 ways: =20 1) Restarting router brings down BFD session with diag code of ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency on the peer. So the peer BFD session will go down but ISIS/OSPF will not treat it as an adjacency down event. =20 2) Restarting router increases the BFD session timer to XXX=20 seconds (XXX > restart time). It can save some state locally to note this. After restart, the restarting router reads the local state and continues the BFD session from the UP state. =20 Thanks Nitin =20 =20 ------_=_NextPart_001_01CA05FD.F639AFED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Nitin,

It is very true that BFD works well in planned = restarts and we don’t need GR extensions there.

But, we have seen issues when bfd is working along = with other time intensive, high priority events.

 

In such a scenario, for GR, we are likely to hit bfd = timer expiry which will be treated as a failure, thus bringing down the = adjacencies (ISIS/OSPF).

One such example is when there are scaled number of = PPPoE sessions on a SP router that also has bfd enabled (with strict = timers).

 

This would mean looking for a workaround at the = architecture level of your router to make this work.

 

In fact, this sort of experience let me into writing = this draft.

Do revert = back for more discussion.

PS: sorry = for that late reply. I had a recent road accident that put me off for a longer = time.

Regards,

A.Palanive= lan

To: <apvelan at = cisco.com>, <rtg-bfd at = ietf.org>

Hi,
 
  You =
really do not need GR extensions to BFD to help =
with
planned restart. There is enough text in =
draft-ietf-bfd-generic 
(Section 4.3.2.2) to help =
you accomplish what you =
want.
 
 At the top of my =
head, I can think of 2 =
ways:
 
1) Restarting =
router brings down BFD session with diag code =
of
   ADMIN_DOWN. ADMIN_DOWN should not =
bring down the adjacency
   on the peer. =
So the peer BFD session will go down but =
ISIS/OSPF
   will not treat it as an =
adjacency down =
event.
 
2) Restarting =
router increases the BFD session timer to XXX =

   seconds (XXX > restart time). =
It can save some state locally
   to note =
this. After restart, the restarting router reads the =
local
   state and continues the BFD =
session from the UP state.
   =

Thanks
Nitin
<= pre> 

 

------_=_NextPart_001_01CA05FD.F639AFED-- From apvelan@cisco.com Thu Jul 16 03:13:21 2009 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 4C89D3A6C3E for ; Thu, 16 Jul 2009 03:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 jsW4qRoDZRnL for ; Thu, 16 Jul 2009 03:13:21 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 5D8D33A6C99 for ; Thu, 16 Jul 2009 03:13:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAyaXkpAaMF0/2dsb2JhbACCKCy0fIgjkRkFhAuBRQ X-IronPort-AV: E=Sophos;i="4.42,410,1243814400"; d="scan'208,217";a="58152464" Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by syd-iport-1.cisco.com with ESMTP; 16 Jul 2009 10:12:47 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6GACjnx029195; Thu, 16 Jul 2009 20:12:46 +1000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6GACOvJ020480; Thu, 16 Jul 2009 10:12:45 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 15:42:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA05FD.F639AFED" Subject: Re: draft-palanivelan-bfd-v2-gr-02 Date: Thu, 16 Jul 2009 15:42:44 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: draft-palanivelan-bfd-v2-gr-02 Thread-Index: AcoF9WgkEb/cwgT2RDibfG313JcnwgACG0Ow From: "Palanivelan A (apvelan)" To: , X-OriginalArrivalTime: 16 Jul 2009 10:12:45.0206 (UTC) FILETIME=[F6637B60:01CA05FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15546; t=1247739167; x=1248603167; c=relaxed/simple; s=syddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=apvelan@cisco.com; z=From:=20=22Palanivelan=20A=20(apvelan)=22=20 |Subject:=20Re=3A=20draft-palanivelan-bfd-v2-gr-02 |Sender:=20; bh=k7OprXnNAmK5h9Ib3LcaHsVyZGqaTi+mR56xoVt7ByY=; b=CyqPIX8yjy3k1RoJTG1zaEOOUN2dK/JJR47q7PPGUMxGobBVBMib7PoIxU LM9GOJkZMVp9XzGjrVHv7KZKlVBRLQaNKlBFHIAbCzw8DzzbTIbfVegnxHQh +5HISaddR/YQ1jez3imAg97UCl7Fmd5nVILnpR04e55/o9SRHK/zM=; Authentication-Results: syd-dkim-1; header.From=apvelan@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); 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, 16 Jul 2009 10:13:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA05FD.F639AFED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nitin, It is very true that BFD works well in planned restarts and we don't need GR extensions there. But, we have seen issues when bfd is working along with other time intensive, high priority events. =20 In such a scenario, for GR, we are likely to hit bfd timer expiry which will be treated as a failure, thus bringing down the adjacencies (ISIS/OSPF). One such example is when there are scaled number of PPPoE sessions on a SP router that also has bfd enabled (with strict timers). =20 This would mean looking for a workaround at the architecture level of your router to make this work. =20 In fact, this sort of experience let me into writing this draft. Do revert back for more discussion. PS: sorry for that late reply. I had a recent road accident that put me off for a longer time. Regards, A.Palanivelan To: >, > * Subject: Re: draft-palanivelan-bfd-v2-gr-01 * From: Nitin Bahadur > * Date: Tue, 3 Feb 2009 16:49:12 -0800 * Delivered-to: rtg-bfd at core3.amsl.com =20 * List-archive: * List-help: * List-id: "RTG Area: Bidirectional Forwarding Detection DT" * List-post: * List-subscribe: , * List-unsubscribe: , * Thread-index: AcmGYmVThhxLBgEuTGCCrADrG/c6fQ=3D=3D * Thread-topic: Re: draft-palanivelan-bfd-v2-gr-01 ________________________________ Hi, =20 You really do not need GR extensions to BFD to help with planned restart. There is enough text in draft-ietf-bfd-generic=20 (Section 4.3.2.2) to help you accomplish what you want. =20 At the top of my head, I can think of 2 ways: =20 1) Restarting router brings down BFD session with diag code of ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency on the peer. So the peer BFD session will go down but ISIS/OSPF will not treat it as an adjacency down event. =20 2) Restarting router increases the BFD session timer to XXX=20 seconds (XXX > restart time). It can save some state locally to note this. After restart, the restarting router reads the local state and continues the BFD session from the UP state. =20 Thanks Nitin =20 =20 ------_=_NextPart_001_01CA05FD.F639AFED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Nitin,

It is very true that BFD works well in planned = restarts and we don’t need GR extensions there.

But, we have seen issues when bfd is working along = with other time intensive, high priority events.

 

In such a scenario, for GR, we are likely to hit bfd = timer expiry which will be treated as a failure, thus bringing down the = adjacencies (ISIS/OSPF).

One such example is when there are scaled number of = PPPoE sessions on a SP router that also has bfd enabled (with strict = timers).

 

This would mean looking for a workaround at the = architecture level of your router to make this work.

 

In fact, this sort of experience let me into writing = this draft.

Do revert = back for more discussion.

PS: sorry = for that late reply. I had a recent road accident that put me off for a longer = time.

Regards,

A.Palanive= lan

To: <apvelan at = cisco.com>, <rtg-bfd at = ietf.org>

Hi,
 
  You =
really do not need GR extensions to BFD to help =
with
planned restart. There is enough text in =
draft-ietf-bfd-generic 
(Section 4.3.2.2) to help =
you accomplish what you =
want.
 
 At the top of my =
head, I can think of 2 =
ways:
 
1) Restarting =
router brings down BFD session with diag code =
of
   ADMIN_DOWN. ADMIN_DOWN should not =
bring down the adjacency
   on the peer. =
So the peer BFD session will go down but =
ISIS/OSPF
   will not treat it as an =
adjacency down =
event.
 
2) Restarting =
router increases the BFD session timer to XXX =

   seconds (XXX > restart time). =
It can save some state locally
   to note =
this. After restart, the restarting router reads the =
local
   state and continues the BFD =
session from the UP state.
   =

Thanks
Nitin
<= pre> 

 

------_=_NextPart_001_01CA05FD.F639AFED-- From nitinb@juniper.net Thu Jul 16 08:55:22 2009 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 0DC8E3A6DA3 for ; Thu, 16 Jul 2009 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Qj+hHRzten9w for ; Thu, 16 Jul 2009 08:55:21 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id D7D3E3A6C94 for ; Thu, 16 Jul 2009 08:55:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSl9NYHmKtxlzMeIJN06XJWO0N8lc8WIN@postini.com; Thu, 16 Jul 2009 08:55:54 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 16 Jul 2009 08:48:20 -0700 From: Nitin Bahadur To: "Palanivelan A (apvelan)" , "rtg-bfd@ietf.org" Date: Thu, 16 Jul 2009 08:49:13 -0700 Subject: Re: draft-palanivelan-bfd-v2-gr-02 Thread-Topic: draft-palanivelan-bfd-v2-gr-02 Thread-Index: AcoF9WgkEb/cwgT2RDibfG313JcnwgAN48eW Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.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, 16 Jul 2009 15:55:22 -0000 Hi, I would think that if there are multiple things happening at the same= time...then the system needs to prioritize BFD over other things in some way or offload bfd to some place that would p= revent bfd from getting affected. Thanks Nitin On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" wrote: Hi Nitin, It is very true that BFD works well in planned restarts and we don't need G= R extensions there. But, we have seen issues when bfd is working along with other time intensiv= e, high priority events. In such a scenario, for GR, we are likely to hit bfd timer expiry which wil= l be treated as a failure, thus bringing down the adjacencies (ISIS/OSPF). One such example is when there are scaled number of PPPoE sessions on a SP = router that also has bfd enabled (with strict timers). This would mean looking for a workaround at the architecture level of your = router to make this work. In fact, this sort of experience let me into writing this draft. Do revert back for more discussion. PS: sorry for that late reply. I had a recent road accident that put me off= for a longer time. Regards, A.Palanivelan To: >, > ________________________________ Hi, You really do not need GR extensions to BFD to help with planned restart. There is enough text in draft-ietf-bfd-generic (Section 4.3.2.2) to help you accomplish what you want. At the top of my head, I can think of 2 ways: 1) Restarting router brings down BFD session with diag code of ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency on the peer. So the peer BFD session will go down but ISIS/OSPF will not treat it as an adjacency down event. 2) Restarting router increases the BFD session timer to XXX seconds (XXX > restart time). It can save some state locally to note this. After restart, the restarting router reads the local state and continues the BFD session from the UP state. Thanks Nitin From apvelan@cisco.com Thu Jul 16 09:39:44 2009 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 4844C3A67AC for ; Thu, 16 Jul 2009 09:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.582 X-Spam-Level: X-Spam-Status: No, score=-4.582 tagged_above=-999 required=5 tests=[AWL=-1.983, 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 y6deysTucWkg for ; Thu, 16 Jul 2009 09:39:43 -0700 (PDT) Received: from syd-iport-2.cisco.com (syd-iport-2.cisco.com [64.104.193.197]) by core3.amsl.com (Postfix) with ESMTP id CC6363A68F7 for ; Thu, 16 Jul 2009 09:38:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGfyXkoKS+eh/2dsb2JhbAC6K4gjkQ8FhAs X-IronPort-AV: E=Sophos;i="4.42,412,1243814400"; d="scan'208";a="55398991" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-2.cisco.com with ESMTP; 16 Jul 2009 16:31:03 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6GGV29n006563; Fri, 17 Jul 2009 00:31:02 +0800 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6GGV1xA020420; Thu, 16 Jul 2009 16:31:02 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 22:01:02 +0530 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: draft-palanivelan-bfd-v2-gr-02 Date: Thu, 16 Jul 2009 22:00:58 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-palanivelan-bfd-v2-gr-02 Thread-Index: AcoF9WgkEb/cwgT2RDibfG313JcnwgAN48eWAAEnRvA= References: From: "Palanivelan A (apvelan)" To: "Nitin Bahadur" , X-OriginalArrivalTime: 16 Jul 2009 16:31:02.0153 (UTC) FILETIME=[CED2BF90:01CA0632] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2766; t=1247761862; x=1248625862; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=apvelan@cisco.com; z=From:=20=22Palanivelan=20A=20(apvelan)=22=20 |Subject:=20RE=3A=20draft-palanivelan-bfd-v2-gr-02 |Sender:=20; bh=DDkw7Nge7pJ5wY21/D4g4thVbr9NhYTeVuqcKxr23Xs=; b=gxnFeJfb4Cul+v5P7pFL9tK0Hr7b/Y3jcjpi5EXCxMEeesM0ysmPkWfThQ fPExN09X0Y/JBaCFcRxZ/rxCPka1qI3cPUdZhYBautkxn0fJRHQCqsyWJu/k 3pSZrZ3z4N+OWqG/gXJptAYin9n+Ti2t90V4dPHfhEVdanzwDFErA=; Authentication-Results: hkg-dkim-1; header.From=apvelan@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); 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, 16 Jul 2009 16:39:44 -0000 Nitin, That's right and system need to prioritize BFD and how easy or how difficult that would be is dependent on the system's design and that is why if bfd as a standard, could provide a easier way out, I guess implementers would prefer it. Also, we cannot always set bfd the highest priority and there would be always be certain events that need to have a higher priority. I have tried explaining that in the draft. Thanks and Regards, A.Palanivelan=20 -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, July 16, 2009 9:19 PM To: Palanivelan A (apvelan); rtg-bfd@ietf.org Subject: Re: draft-palanivelan-bfd-v2-gr-02 Hi, I would think that if there are multiple things happening at the same time...then the system needs to prioritize BFD over other things in some way or offload bfd to some place that would prevent bfd from getting affected. Thanks Nitin On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" wrote: Hi Nitin, It is very true that BFD works well in planned restarts and we don't need GR extensions there. But, we have seen issues when bfd is working along with other time intensive, high priority events. In such a scenario, for GR, we are likely to hit bfd timer expiry which will be treated as a failure, thus bringing down the adjacencies (ISIS/OSPF). One such example is when there are scaled number of PPPoE sessions on a SP router that also has bfd enabled (with strict timers). This would mean looking for a workaround at the architecture level of your router to make this work. In fact, this sort of experience let me into writing this draft. Do revert back for more discussion. PS: sorry for that late reply. I had a recent road accident that put me off for a longer time. Regards, A.Palanivelan To: >, > ________________________________ Hi, You really do not need GR extensions to BFD to help with planned restart. There is enough text in draft-ietf-bfd-generic (Section 4.3.2.2) to help you accomplish what you want. At the top of my head, I can think of 2 ways: 1) Restarting router brings down BFD session with diag code of ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency on the peer. So the peer BFD session will go down but ISIS/OSPF will not treat it as an adjacency down event. 2) Restarting router increases the BFD session timer to XXX seconds (XXX > restart time). It can save some state locally to note this. After restart, the restarting router reads the local state and continues the BFD session from the UP state. Thanks Nitin From vishwas.ietf@gmail.com Thu Jul 16 09:47:14 2009 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 C61D43A6BEE for ; Thu, 16 Jul 2009 09:47:14 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPrGr5au+bAZ for ; Thu, 16 Jul 2009 09:47:13 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 9B1BC3A67AC for ; Thu, 16 Jul 2009 09:47:13 -0700 (PDT) Received: by gxk9 with SMTP id 9so405605gxk.13 for ; Thu, 16 Jul 2009 09:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1cf7Ak6SDhavn7J06okQMwDjnD+TgvvniSzLAfBMXxQ=; b=bijA0xjggnG19zlBoKXpeZB2KQhyycjvoJwa6tTv8/EPhB0+nEljwn/cJZjIxPp71J j7k17DneqXoECt4/UV3Nwoq7QkpLDjMy+cAO6VnqLiQusBPcFXnt5aW2OnuDEmwpGseb Ecn8a2ubtSpzTuB98R2q6TaZeKLUz5vEnh/T4= 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=quFIJ56MvFgDT42kcaaIDh5Rb8rou+/buVkTemVLeRxwaezgPeM0XQ6NFBu7+3042U l2mc9mxtT8zWnulzc4fOC5HS0NlL4CVjWVJ2ZezNvbjJ0u6d+eb4tKZ1wmbKnvkgFj7a JH4AYlwBckIC6n8ej219VpwviO6nO2mCBUJ1U= MIME-Version: 1.0 Received: by 10.151.42.6 with SMTP id u6mr89255ybj.204.1247762440403; Thu, 16 Jul 2009 09:40:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Jul 2009 09:40:40 -0700 Message-ID: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> Subject: Re: draft-palanivelan-bfd-v2-gr-02 From: Vishwas Manral To: Nitin Bahadur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtg-bfd@ietf.org" , "Palanivelan A \(apvelan\)" 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, 16 Jul 2009 16:47:14 -0000 Hi A. Palanivelan, I agree with Nitin here. If BFD packets are not prioritized over others, we need to fix that instead of any other changes. Thanks, Vishwas On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur wrote: > Hi, > > =A0 =A0 =A0I would think that if there are multiple things happening at t= he same time...then the system needs to prioritize > BFD over other things in some way or offload bfd to some place that would= prevent bfd from getting affected. > > Thanks > Nitin > > On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" wrote: > > Hi Nitin, > It is very true that BFD works well in planned restarts and we don't need= GR extensions there. > But, we have seen issues when bfd is working along with other time intens= ive, high priority events. > > In such a scenario, for GR, we are likely to hit bfd timer expiry which w= ill be treated as a failure, thus bringing down the adjacencies (ISIS/OSPF)= . > One such example is when there are scaled number of PPPoE sessions on a S= P router that also has bfd enabled (with strict timers). > > This would mean looking for a workaround at the architecture level of you= r router to make this work. > > In fact, this sort of experience let me into writing this draft. > Do revert back for more discussion. > PS: sorry for that late reply. I had a recent road accident that put me o= ff for a longer time. > Regards, > A.Palanivelan > To: >, > > > ________________________________ > > Hi, > > =A0You really do not need GR extensions to BFD to help with > planned restart. There is enough text in draft-ietf-bfd-generic > (Section 4.3.2.2) to help you accomplish what you want. > > =A0At the top of my head, I can think of 2 ways: > > 1) Restarting router brings down BFD session with diag code of > =A0 ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency > =A0 on the peer. So the peer BFD session will go down but ISIS/OSPF > =A0 will not treat it as an adjacency down event. > > 2) Restarting router increases the BFD session timer to XXX > =A0 seconds (XXX > restart time). It can save some state locally > =A0 to note this. After restart, the restarting router reads the local > =A0 state and continues the BFD session from the UP state. > > Thanks > Nitin > From apvelan@cisco.com Thu Jul 16 09:54:15 2009 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 055ED3A6918 for ; Thu, 16 Jul 2009 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 apIx+hYL6mRj for ; Thu, 16 Jul 2009 09:54:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D8E6C3A67AC for ; Thu, 16 Jul 2009 09:53:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAf4XkqrR7PE/2dsb2JhbAC6SIgjkRUFhAs X-IronPort-AV: E=Sophos;i="4.42,412,1243814400"; d="scan'208";a="177465505" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2009 16:52:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6GGqkpN018407; Thu, 16 Jul 2009 09:52:46 -0700 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6GGqivW015401; Thu, 16 Jul 2009 16:52:46 GMT Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 22:22:44 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-palanivelan-bfd-v2-gr-02 Date: Thu, 16 Jul 2009 22:22:39 +0530 Message-ID: In-Reply-To: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-palanivelan-bfd-v2-gr-02 Thread-Index: AcoGNC9sscqn3JkHSw2u4SvFKPDoQwAAEj+Q References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> From: "Palanivelan A (apvelan)" To: "Vishwas Manral" , "Nitin Bahadur" X-OriginalArrivalTime: 16 Jul 2009 16:52:44.0742 (UTC) FILETIME=[D73A0E60:01CA0635] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3207; t=1247763166; x=1248627166; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=apvelan@cisco.com; z=From:=20=22Palanivelan=20A=20(apvelan)=22=20 |Subject:=20RE=3A=20draft-palanivelan-bfd-v2-gr-02 |Sender:=20; bh=abWqL7jGt4KG2Ei8NSUApH7K0FTUKDAmdiRcE0lZddU=; b=J5w3TbuQcuT71AUYFVmurTVmPvSmh6HYzyFS3AJeazwHDxf4qkxAKtPHcv X4WUe3r6AFd0c5hpskgpg4FiU6ySdtLVG7c6QtMy3n0Rgla1d9c5RSJHqZCG G5jRwOi6gJ; Authentication-Results: sj-dkim-4; header.From=apvelan@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 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: Thu, 16 Jul 2009 16:54:15 -0000 Hi Vishwas, Like I have explained in section 3.2, a SP responding to a session = renewal request from the subscribers=20 will be the highest priority and when this happens during a GR, and with = scaled subscribers(very likely in real scenario), implementers need to look at other ways to prevent bfd from getting = affected. And again don't you think a standards way of handling this scenario = would benefit the customers, using equipments from multiple vendors. Thanks and Regards, A.Palanivelan -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Thursday, July 16, 2009 10:11 PM To: Nitin Bahadur Cc: Palanivelan A (apvelan); rtg-bfd@ietf.org Subject: Re: draft-palanivelan-bfd-v2-gr-02 Hi A. Palanivelan, I agree with Nitin here. If BFD packets are not prioritized over others, we need to fix that instead of any other changes. Thanks, Vishwas On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur = wrote: > Hi, > > =A0 =A0 =A0I would think that if there are multiple things happening = at the same time...then the system needs to prioritize > BFD over other things in some way or offload bfd to some place that = would prevent bfd from getting affected. > > Thanks > Nitin > > On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" = wrote: > > Hi Nitin, > It is very true that BFD works well in planned restarts and we don't = need GR extensions there. > But, we have seen issues when bfd is working along with other time = intensive, high priority events. > > In such a scenario, for GR, we are likely to hit bfd timer expiry = which will be treated as a failure, thus bringing down the adjacencies = (ISIS/OSPF). > One such example is when there are scaled number of PPPoE sessions on = a SP router that also has bfd enabled (with strict timers). > > This would mean looking for a workaround at the architecture level of = your router to make this work. > > In fact, this sort of experience let me into writing this draft. > Do revert back for more discussion. > PS: sorry for that late reply. I had a recent road accident that put = me off for a longer time. > Regards, > A.Palanivelan > To: >, > > > ________________________________ > > Hi, > > =A0You really do not need GR extensions to BFD to help with > planned restart. There is enough text in draft-ietf-bfd-generic > (Section 4.3.2.2) to help you accomplish what you want. > > =A0At the top of my head, I can think of 2 ways: > > 1) Restarting router brings down BFD session with diag code of > =A0 ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency > =A0 on the peer. So the peer BFD session will go down but ISIS/OSPF > =A0 will not treat it as an adjacency down event. > > 2) Restarting router increases the BFD session timer to XXX > =A0 seconds (XXX > restart time). It can save some state locally > =A0 to note this. After restart, the restarting router reads the local > =A0 state and continues the BFD session from the UP state. > > Thanks > Nitin > From vishwas.ietf@gmail.com Thu Jul 16 11:22:18 2009 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 989313A6DB5 for ; Thu, 16 Jul 2009 11:22:18 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxYG4Tb8u1+U for ; Thu, 16 Jul 2009 11:22:17 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id 59C653A6D94 for ; Thu, 16 Jul 2009 11:22:17 -0700 (PDT) Received: by gxk9 with SMTP id 9so512261gxk.13 for ; Thu, 16 Jul 2009 11:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w65rJbggxVO1zBOcVsTfmmf11B1MdZHsKQeIFO5Ukxw=; b=DOUcIDdw+pVhjVlmltC5Qag4JcHzclZB5jBGdoDNpbqfKRABSsiZTuVfyB0LYG4LU/ Lq858DUVYO7VU6RdCGIF9WmRfT/LSTbeGawBo6IMaYk6OcxqmtKZdnYOj27YUALyINpu fke317EjTgYvrucVMXejl854T8IUlE9iQcUHQ= 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=lRUqhr/I0yEnzZt0i/EqI0/Xd+rm5iIqHnXwIDzn+5bQdgX8e8HGHpn0spY/iPa5H2 OiZxS2V2/fmh4BcXeRX6BCoXl+yzghR5k3naR5CKDBzvpOT3ZD8tM9Ty+q/AtHpR2oIU JvSg1hILn+S7txS3tJ3JRKslyixC8Zy/mQEqE= MIME-Version: 1.0 Received: by 10.151.149.8 with SMTP id b8mr243965ybo.275.1247768568355; Thu, 16 Jul 2009 11:22:48 -0700 (PDT) In-Reply-To: References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> Date: Thu, 16 Jul 2009 11:22:48 -0700 Message-ID: <77ead0ec0907161122m6738d53dj176b47f313c91709@mail.gmail.com> Subject: Re: draft-palanivelan-bfd-v2-gr-02 From: Vishwas Manral To: "Palanivelan A (apvelan)" 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: Thu, 16 Jul 2009 18:22:18 -0000 Hi A.Palanivel, A simple solution to this is treat the session renewal trigger messages as triggers for BFD to say that the peer is up. So whenever I get a valid packet from the peer, treat it as if you got a valid BFD packet (ofcourse you need to be careful when doing this - based on your system). Thanks, Vishwas On Thu, Jul 16, 2009 at 9:52 AM, Palanivelan A (apvelan) wrote: > Hi Vishwas, > > Like I have explained in section 3.2, a SP responding to a session renewa= l request from the subscribers > will be the highest priority and when this happens during a GR, and with = scaled subscribers(very likely in real scenario), > implementers need to look at other ways to prevent bfd from getting affec= ted. > > And again don't you think a standards way of handling this scenario would= benefit the customers, using equipments from multiple vendors. > > Thanks and Regards, > A.Palanivelan > > > > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Thursday, July 16, 2009 10:11 PM > To: Nitin Bahadur > Cc: Palanivelan A (apvelan); rtg-bfd@ietf.org > Subject: Re: draft-palanivelan-bfd-v2-gr-02 > > Hi A. Palanivelan, > > I agree with Nitin here. If BFD packets are not prioritized over > others, we need to fix that instead of any other changes. > > Thanks, > Vishwas > > On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur wrote: >> Hi, >> >> =A0 =A0 =A0I would think that if there are multiple things happening at = the same time...then the system needs to prioritize >> BFD over other things in some way or offload bfd to some place that woul= d prevent bfd from getting affected. >> >> Thanks >> Nitin >> >> On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" wrote: >> >> Hi Nitin, >> It is very true that BFD works well in planned restarts and we don't nee= d GR extensions there. >> But, we have seen issues when bfd is working along with other time inten= sive, high priority events. >> >> In such a scenario, for GR, we are likely to hit bfd timer expiry which = will be treated as a failure, thus bringing down the adjacencies (ISIS/OSPF= ). >> One such example is when there are scaled number of PPPoE sessions on a = SP router that also has bfd enabled (with strict timers). >> >> This would mean looking for a workaround at the architecture level of yo= ur router to make this work. >> >> In fact, this sort of experience let me into writing this draft. >> Do revert back for more discussion. >> PS: sorry for that late reply. I had a recent road accident that put me = off for a longer time. >> Regards, >> A.Palanivelan >> To: >, > >> >> ________________________________ >> >> Hi, >> >> =A0You really do not need GR extensions to BFD to help with >> planned restart. There is enough text in draft-ietf-bfd-generic >> (Section 4.3.2.2) to help you accomplish what you want. >> >> =A0At the top of my head, I can think of 2 ways: >> >> 1) Restarting router brings down BFD session with diag code of >> =A0 ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency >> =A0 on the peer. So the peer BFD session will go down but ISIS/OSPF >> =A0 will not treat it as an adjacency down event. >> >> 2) Restarting router increases the BFD session timer to XXX >> =A0 seconds (XXX > restart time). It can save some state locally >> =A0 to note this. After restart, the restarting router reads the local >> =A0 state and continues the BFD session from the UP state. >> >> Thanks >> Nitin >> > From satyamsinha@live.com Thu Jul 16 16:49:45 2009 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 884DA3A6DB3 for ; Thu, 16 Jul 2009 16:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, 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 3vFLo5Ia6E95 for ; Thu, 16 Jul 2009 16:49:44 -0700 (PDT) Received: from bay0-omc3-s34.bay0.hotmail.com (bay0-omc3-s34.bay0.hotmail.com [65.54.246.234]) by core3.amsl.com (Postfix) with ESMTP id 63A0328C259 for ; Thu, 16 Jul 2009 16:49:28 -0700 (PDT) Received: from BAY117-W6 ([207.46.8.41]) by bay0-omc3-s34.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 16:49:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_72dc3a54-aea2-4974-8834-16856be4a2a9_" X-Originating-IP: [64.47.51.158] From: Satyam Sinha To: , Vishwas Manral , Subject: RE: draft-palanivelan-bfd-v2-gr-02 Date: Thu, 16 Jul 2009 16:49:40 -0700 Importance: Normal In-Reply-To: References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2009 23:49:40.0549 (UTC) FILETIME=[15CF4750:01CA0670] 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: Thu, 16 Jul 2009 23:49:45 -0000 --_72dc3a54-aea2-4974-8834-16856be4a2a9_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi=2C As Nitin explained=2C the base draft can support this functionality. If we = add the new "easier" ways=2C others will have to implement it as well for n= o potential benefit as their architecture can take care of the prioritizing= . I think this is a system architecture issue and so we should make minor cha= nges to the architecture as opposed to changing the standard. Regards=2C Satyam =20 > Subject: RE: draft-palanivelan-bfd-v2-gr-02 > Date: Thu=2C 16 Jul 2009 22:22:39 +0530 > From: apvelan@cisco.com > To: vishwas.ietf@gmail.com=3B nitinb@juniper.net > CC: rtg-bfd@ietf.org >=20 > Hi Vishwas=2C >=20 > Like I have explained in section 3.2=2C a SP responding to a session rene= wal request from the subscribers=20 > will be the highest priority and when this happens during a GR=2C and wit= h scaled subscribers(very likely in real scenario)=2C > implementers need to look at other ways to prevent bfd from getting affec= ted. >=20 > And again don't you think a standards way of handling this scenario would= benefit the customers=2C using equipments from multiple vendors. >=20 > Thanks and Regards=2C > A.Palanivelan >=20 >=20 >=20 > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 > Sent: Thursday=2C July 16=2C 2009 10:11 PM > To: Nitin Bahadur > Cc: Palanivelan A (apvelan)=3B rtg-bfd@ietf.org > Subject: Re: draft-palanivelan-bfd-v2-gr-02 >=20 > Hi A. Palanivelan=2C >=20 > I agree with Nitin here. If BFD packets are not prioritized over > others=2C we need to fix that instead of any other changes. >=20 > Thanks=2C > Vishwas >=20 > On Thu=2C Jul 16=2C 2009 at 8:49 AM=2C Nitin Bahadur = wrote: > > Hi=2C > > > > I would think that if there are multiple things happening at the s= ame time...then the system needs to prioritize > > BFD over other things in some way or offload bfd to some place that wou= ld prevent bfd from getting affected. > > > > Thanks > > Nitin > > > > On 7/16/09 2:11 AM=2C "Palanivelan A (apvelan)" wro= te: > > > > Hi Nitin=2C > > It is very true that BFD works well in planned restarts and we don't ne= ed GR extensions there. > > But=2C we have seen issues when bfd is working along with other time in= tensive=2C high priority events. > > > > In such a scenario=2C for GR=2C we are likely to hit bfd timer expiry w= hich will be treated as a failure=2C thus bringing down the adjacencies (IS= IS/OSPF). > > One such example is when there are scaled number of PPPoE sessions on a= SP router that also has bfd enabled (with strict timers). > > > > This would mean looking for a workaround at the architecture level of y= our router to make this work. > > > > In fact=2C this sort of experience let me into writing this draft. > > Do revert back for more discussion. > > PS: sorry for that late reply. I had a recent road accident that put me= off for a longer time. > > Regards=2C > > A.Palanivelan > > To: >=2C > > > > > ________________________________ > > > > Hi=2C > > > > You really do not need GR extensions to BFD to help with > > planned restart. There is enough text in draft-ietf-bfd-generic > > (Section 4.3.2.2) to help you accomplish what you want. > > > > At the top of my head=2C I can think of 2 ways: > > > > 1) Restarting router brings down BFD session with diag code of > > ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency > > on the peer. So the peer BFD session will go down but ISIS/OSPF > > will not treat it as an adjacency down event. > > > > 2) Restarting router increases the BFD session timer to XXX > > seconds (XXX > restart time). It can save some state locally > > to note this. After restart=2C the restarting router reads the local > > state and continues the BFD session from the UP state. > > > > Thanks > > Nitin > > _________________________________________________________________ Hotmail=AE has ever-growing storage! Don=92t worry about storage limits.=20 http://windowslive.com/Tutorial/Hotmail/Storage?ocid=3DTXT_TAGLM_WL_HM_Tuto= rial_Storage_062009= --_72dc3a54-aea2-4974-8834-16856be4a2a9_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi=2C

As Nitin explained=2C the base draft can support this function= ality. If we add the new "easier" ways=2C others will have to implement it = as well for no potential benefit as their architecture can take care of the= prioritizing.

I think this is a system architecture issue and so we= should make minor changes to the architecture as opposed to changing the s= tandard.

Regards=2C

Satyam =3B

>=3B Subject: RE= : draft-palanivelan-bfd-v2-gr-02
>=3B Date: Thu=2C 16 Jul 2009 22:22:3= 9 +0530
>=3B From: apvelan@cisco.com
>=3B To: vishwas.ietf@gmail.= com=3B nitinb@juniper.net
>=3B CC: rtg-bfd@ietf.org
>=3B
>= =3B Hi Vishwas=2C
>=3B
>=3B Like I have explained in section 3.2= =2C a SP responding to a session renewal request from the subscribers
&= gt=3B will be the highest priority and when this happens during a GR=2C and= with scaled subscribers(very likely in real scenario)=2C
>=3B impleme= nters need to look at other ways to prevent bfd from getting affected.
&= gt=3B
>=3B And again don't you think a standards way of handling this= scenario would benefit the customers=2C using equipments from multiple ven= dors.
>=3B
>=3B Thanks and Regards=2C
>=3B A.Palanivelan>=3B
>=3B
>=3B
>=3B -----Original Message-----
>= =3B From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
>=3B Sent: T= hursday=2C July 16=2C 2009 10:11 PM
>=3B To: Nitin Bahadur
>=3B C= c: Palanivelan A (apvelan)=3B rtg-bfd@ietf.org
>=3B Subject: Re: draft= -palanivelan-bfd-v2-gr-02
>=3B
>=3B Hi A. Palanivelan=2C
>= =3B
>=3B I agree with Nitin here. If BFD packets are not prioritized = over
>=3B others=2C we need to fix that instead of any other changes.<= br>>=3B
>=3B Thanks=2C
>=3B Vishwas
>=3B
>=3B On Th= u=2C Jul 16=2C 2009 at 8:49 AM=2C Nitin Bahadur<=3Bnitinb@juniper.net>= =3B wrote:
>=3B >=3B Hi=2C
>=3B >=3B
>=3B >=3B  = =3B  =3B  =3BI would think that if there are multiple things happen= ing at the same time...then the system needs to prioritize
>=3B >=3B= BFD over other things in some way or offload bfd to some place that would = prevent bfd from getting affected.
>=3B >=3B
>=3B >=3B Thanks=
>=3B >=3B Nitin
>=3B >=3B
>=3B >=3B On 7/16/09 2:11 A= M=2C "Palanivelan A (apvelan)" <=3Bapvelan@cisco.com>=3B wrote:
>= =3B >=3B
>=3B >=3B Hi Nitin=2C
>=3B >=3B It is very true th= at BFD works well in planned restarts and we don't need GR extensions there= .
>=3B >=3B But=2C we have seen issues when bfd is working along wit= h other time intensive=2C high priority events.
>=3B >=3B
>=3B = >=3B In such a scenario=2C for GR=2C we are likely to hit bfd timer expir= y which will be treated as a failure=2C thus bringing down the adjacencies = (ISIS/OSPF).
>=3B >=3B One such example is when there are scaled num= ber of PPPoE sessions on a SP router that also has bfd enabled (with strict= timers).
>=3B >=3B
>=3B >=3B This would mean looking for a w= orkaround at the architecture level of your router to make this work.
&g= t=3B >=3B
>=3B >=3B In fact=2C this sort of experience let me into= writing this draft.
>=3B >=3B Do revert back for more discussion.>=3B >=3B PS: sorry for that late reply. I had a recent road accident= that put me off for a longer time.
>=3B >=3B Regards=2C
>=3B &= gt=3B A.Palanivelan
>=3B >=3B To: <=3Bapvelan at cisco.com <=3Bm= ailto:apvelan@DOMAIN.HIDDEN>=3B >=3B=2C <=3Brtg-bfd at ietf.org <= =3Bmailto:rtg-bfd@DOMAIN.HIDDEN>=3B >=3B
>=3B >=3B
>=3B >= =3B ________________________________
>=3B >=3B
>=3B >=3B Hi= =2C
>=3B >=3B
>=3B >=3B  =3BYou really do not need GR ext= ensions to BFD to help with
>=3B >=3B planned restart. There is enou= gh text in draft-ietf-bfd-generic
>=3B >=3B (Section 4.3.2.2) to hel= p you accomplish what you want.
>=3B >=3B
>=3B >=3B  =3BA= t the top of my head=2C I can think of 2 ways:
>=3B >=3B
>=3B &= gt=3B 1) Restarting router brings down BFD session with diag code of
>= =3B >=3B  =3B ADMIN_DOWN. ADMIN_DOWN should not bring down the adjace= ncy
>=3B >=3B  =3B on the peer. So the peer BFD session will go = down but ISIS/OSPF
>=3B >=3B  =3B will not treat it as an adjace= ncy down event.
>=3B >=3B
>=3B >=3B 2) Restarting router incr= eases the BFD session timer to XXX
>=3B >=3B  =3B seconds (XXX &= gt=3B restart time). It can save some state locally
>=3B >=3B  = =3B to note this. After restart=2C the restarting router reads the local>=3B >=3B  =3B state and continues the BFD session from the UP sta= te.
>=3B >=3B
>=3B >=3B Thanks
>=3B >=3B Nitin
>= =3B >=3B

Hotmail=AE has ever-growing storage! Don=92t worr= y about storage limits. Che= ck it out. = --_72dc3a54-aea2-4974-8834-16856be4a2a9_-- From dward@cisco.com Thu Jul 16 17:41:31 2009 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 DC68128C0E1 for ; Thu, 16 Jul 2009 17:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2t6mxxWylxw for ; Thu, 16 Jul 2009 17:41:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B9ECD3A6A85 for ; Thu, 16 Jul 2009 17:41:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,414,1243814400"; d="scan'208";a="215255217" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 17 Jul 2009 00:42:04 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6H0g46v016399; Thu, 16 Jul 2009 17:42:04 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6H0g3Ec006126; Fri, 17 Jul 2009 00:42:04 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 20:42:03 -0400 Received: from [127.0.0.1] ([64.102.8.172]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 20:42:03 -0400 Message-Id: <00BFE893-FDB3-44E6-B10F-28BC5A795AC4@cisco.com> From: David Ward To: Vishwas Manral In-Reply-To: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: draft-palanivelan-bfd-v2-gr-02 Date: Thu, 16 Jul 2009 19:42:01 -0500 References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 17 Jul 2009 00:42:03.0306 (UTC) FILETIME=[6709F0A0:01CA0677] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3295; t=1247791324; x=1248655324; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20draft-palanivelan-bfd-v2-gr-02 |Sender:=20; bh=KtxOvH/Dsc9UQS4xmbNzLPBLmCr0ovLRcareU8LD9+4=; b=OvahIQqfkMbGTkj5k6fVpCBGUc/qTvlNKCuRLjt2d8NzpKrYFVMnx0f623 8UvuGRIG9vDdtMzLgkE0PD2FY7lxq6Gx58+mLozDRZSO1qtbcrlGfopNXNPy uFZgoRKyaP; Authentication-Results: sj-dkim-4; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "rtg-bfd@ietf.org" , "Palanivelan A \(apvelan\)" , David Ward 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, 17 Jul 2009 00:41:31 -0000 One change to the BFD base spec as requested by the IESG is a congestion control mechanism. We've come to conclusion with the transport, internet and routing ADs on the algorithm and you will see it in the last rev of the base spec. In a very short summary, if one can detect that there is persistent congestion then use the adaptive timers to send fewer packets and see if the congestion clears. Then ramp them back up slowly until self-stabilized and no observable, persistent congestion is detected. In the case described below, there doesn't need to be protocol extensions to cover this issue. There are many ways system design choices can impact your implementation. -DWard On Jul 16, 2009, at 11:40 AM, Vishwas Manral wrote: > Hi A. Palanivelan, > > I agree with Nitin here. If BFD packets are not prioritized over > others, we need to fix that instead of any other changes. > > Thanks, > Vishwas > > On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur > wrote: >> Hi, >> >> I would think that if there are multiple things happening at >> the same time...then the system needs to prioritize >> BFD over other things in some way or offload bfd to some place that >> would prevent bfd from getting affected. >> >> Thanks >> Nitin >> >> On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" >> wrote: >> >> Hi Nitin, >> It is very true that BFD works well in planned restarts and we >> don't need GR extensions there. >> But, we have seen issues when bfd is working along with other time >> intensive, high priority events. >> >> In such a scenario, for GR, we are likely to hit bfd timer expiry >> which will be treated as a failure, thus bringing down the >> adjacencies (ISIS/OSPF). >> One such example is when there are scaled number of PPPoE sessions >> on a SP router that also has bfd enabled (with strict timers). >> >> This would mean looking for a workaround at the architecture level >> of your router to make this work. >> >> In fact, this sort of experience let me into writing this draft. >> Do revert back for more discussion. >> PS: sorry for that late reply. I had a recent road accident that >> put me off for a longer time. >> Regards, >> A.Palanivelan >> To: >, > bfd at ietf.org > >> >> ________________________________ >> >> Hi, >> >> You really do not need GR extensions to BFD to help with >> planned restart. There is enough text in draft-ietf-bfd-generic >> (Section 4.3.2.2) to help you accomplish what you want. >> >> At the top of my head, I can think of 2 ways: >> >> 1) Restarting router brings down BFD session with diag code of >> ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency >> on the peer. So the peer BFD session will go down but ISIS/OSPF >> will not treat it as an adjacency down event. >> >> 2) Restarting router increases the BFD session timer to XXX >> seconds (XXX > restart time). It can save some state locally >> to note this. After restart, the restarting router reads the local >> state and continues the BFD session from the UP state. >> >> Thanks >> Nitin >> From vishwas.ietf@gmail.com Mon Jul 20 14:24:44 2009 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 26BC13A6834 for ; Mon, 20 Jul 2009 14:24:44 -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 YqUbe8cuObRQ for ; Mon, 20 Jul 2009 14:24:37 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 0F2FC3A67D7 for ; Mon, 20 Jul 2009 14:24:36 -0700 (PDT) Received: by yxe34 with SMTP id 34so4267785yxe.29 for ; Mon, 20 Jul 2009 14:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1478Y/GvAb6TzzysqxHzjQIUpmmbcpldsB3zrqcloJk=; b=J7hvHKIvr0rcJq23Es7WISBu3HDMOopd0XdW9o+NbkiyIiBzHH6nw3iDVA9a4iU7aU gdr2UOUh6lFWm5qKQ9WMaI7reTDEtDcXl8/tCjSGK+OXNiGgZUjB6C6l3XOlA1IAVHuW F7+bv+YTHXFPSWUnCffWZ17ea4ThEIXJWS7h8= 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=iW9+IkKCB/OkgQNDy6c3bY4sgEzPVKXdmXoCQ3h2re5u88VqcFX1JZuN+QMG6cjfTg gEwwoonzMCvxSjoOGGUn6D5yhF/Ndghryjxr/HT7GlkpCKb7UrquKs5t80JCnP0ohIT+ 4+JQJwzdXkCPRpeQI3w4ER0EhUQ+q9+G5jKRI= MIME-Version: 1.0 Received: by 10.151.49.21 with SMTP id b21mr7482478ybk.248.1248124897624; Mon, 20 Jul 2009 14:21:37 -0700 (PDT) In-Reply-To: <00BFE893-FDB3-44E6-B10F-28BC5A795AC4@cisco.com> References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> <00BFE893-FDB3-44E6-B10F-28BC5A795AC4@cisco.com> Date: Mon, 20 Jul 2009 14:21:37 -0700 Message-ID: <77ead0ec0907201421t356d3838ge222266b93ba77b6@mail.gmail.com> Subject: Re: draft-palanivelan-bfd-v2-gr-02 From: Vishwas Manral To: David Ward Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Palanivelan A \(apvelan\)" , "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, 20 Jul 2009 21:24:44 -0000 Hi David, Thanks for sharing the updates with us. So is the mechanism to do detect 'persistent congestion' also mentioned, or is that left out of scope. Also during congestion do we increase the 'Minimum receive interval' or the 'transmit interval' or both. So can the congestion assumed to be in both directions or only in the direction of the incoming flow? Thanks again, Vishwas On Thu, Jul 16, 2009 at 5:42 PM, David Ward wrote: > One change to the BFD base spec as requested by the IESG is a congestion > control mechanism. We've come to conclusion with the transport, internet = and > routing ADs on the algorithm and you will see it in the last rev of the b= ase > spec. In a very short summary, if one can detect that there is persistent > congestion then use the adaptive timers to send fewer packets and see if = the > congestion clears. Then ramp them back up slowly until self-stabilized an= d > no observable, persistent congestion is detected. > > In the case described below, there doesn't need to be protocol extensions= to > cover this issue. =A0There are many ways system design choices can impact= your > implementation. > > -DWard > > On Jul 16, 2009, at 11:40 AM, Vishwas Manral wrote: > >> Hi A. Palanivelan, >> >> I agree with Nitin here. If BFD packets are not prioritized over >> others, we need to fix that instead of any other changes. >> >> Thanks, >> Vishwas >> >> On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur wrote= : >>> >>> Hi, >>> >>> =A0 =A0 I would think that if there are multiple things happening at th= e same >>> time...then the system needs to prioritize >>> BFD over other things in some way or offload bfd to some place that wou= ld >>> prevent bfd from getting affected. >>> >>> Thanks >>> Nitin >>> >>> On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" wrote= : >>> >>> Hi Nitin, >>> It is very true that BFD works well in planned restarts and we don't ne= ed >>> GR extensions there. >>> But, we have seen issues when bfd is working along with other time >>> intensive, high priority events. >>> >>> In such a scenario, for GR, we are likely to hit bfd timer expiry which >>> will be treated as a failure, thus bringing down the adjacencies >>> (ISIS/OSPF). >>> One such example is when there are scaled number of PPPoE sessions on a >>> SP router that also has bfd enabled (with strict timers). >>> >>> This would mean looking for a workaround at the architecture level of >>> your router to make this work. >>> >>> In fact, this sort of experience let me into writing this draft. >>> Do revert back for more discussion. >>> PS: sorry for that late reply. I had a recent road accident that put me >>> off for a longer time. >>> Regards, >>> A.Palanivelan >>> To: >, >> ietf.org > >>> >>> ________________________________ >>> >>> Hi, >>> >>> =A0You really do not need GR extensions to BFD to help with >>> planned restart. There is enough text in draft-ietf-bfd-generic >>> (Section 4.3.2.2) to help you accomplish what you want. >>> >>> =A0At the top of my head, I can think of 2 ways: >>> >>> 1) Restarting router brings down BFD session with diag code of >>> =A0ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency >>> =A0on the peer. So the peer BFD session will go down but ISIS/OSPF >>> =A0will not treat it as an adjacency down event. >>> >>> 2) Restarting router increases the BFD session timer to XXX >>> =A0seconds (XXX > restart time). It can save some state locally >>> =A0to note this. After restart, the restarting router reads the local >>> =A0state and continues the BFD session from the UP state. >>> >>> Thanks >>> Nitin >>> > > From dward@cisco.com Mon Jul 20 15:35:57 2009 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 96A3C3A6AB1 for ; Mon, 20 Jul 2009 15:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.169 X-Spam-Level: X-Spam-Status: No, score=-5.169 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] 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 g+-UblssHvqP for ; Mon, 20 Jul 2009 15:35:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 980993A68E0 for ; Mon, 20 Jul 2009 15:35:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,236,1246838400"; d="scan'208";a="51065914" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2009 22:33:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6KMXsum012703; Mon, 20 Jul 2009 18:33:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6KMXsdU000611; Mon, 20 Jul 2009 22:33:54 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 18:33:54 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 18:33:53 -0400 Message-Id: From: David Ward To: Vishwas Manral In-Reply-To: <77ead0ec0907201421t356d3838ge222266b93ba77b6@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: draft-palanivelan-bfd-v2-gr-02 Date: Mon, 20 Jul 2009 17:33:50 -0500 References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> <00BFE893-FDB3-44E6-B10F-28BC5A795AC4@cisco.com> <77ead0ec0907201421t356d3838ge222266b93ba77b6@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 20 Jul 2009 22:33:53.0907 (UTC) FILETIME=[2973C430:01CA098A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4304; t=1248129234; x=1248993234; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20draft-palanivelan-bfd-v2-gr-02 |Sender:=20 |To:=20Vishwas=20Manral=20; bh=tHt+soPyPy0qb+k3VblwNvhnI2uMlJRigICLmU9yn2g=; b=TkrwTKryQP3StDQq5eVcMfMnMCnTUs7s88Q8p9jWSZ+y/N3CLAL23+qrRO tw2peU/pGlLqDBRzRpX0lwmSuqdgQc4G/mglTxTawrzb86pKwZPE+5M+eMEF zpiGOgBOsv; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "rtg-bfd@ietf.org" , "Palanivelan A \(apvelan\)" , David Ward 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, 20 Jul 2009 22:35:57 -0000 V - The method to detect persistent congestion will have enough rules for the BFD packet loss over a stated interval. A system can only usefully detect in the rx direction. -DWard On Jul 20, 2009, at 4:21 PM, Vishwas Manral wrote: > Hi David, > > Thanks for sharing the updates with us. > > So is the mechanism to do detect 'persistent congestion' also > mentioned, or is that left out of scope. Also during congestion do we > increase the 'Minimum receive interval' or the 'transmit interval' or > both. So can the congestion assumed to be in both directions or only > in the direction of the incoming flow? > > Thanks again, > Vishwas > > On Thu, Jul 16, 2009 at 5:42 PM, David Ward wrote: >> One change to the BFD base spec as requested by the IESG is a >> congestion >> control mechanism. We've come to conclusion with the transport, >> internet and >> routing ADs on the algorithm and you will see it in the last rev of >> the base >> spec. In a very short summary, if one can detect that there is >> persistent >> congestion then use the adaptive timers to send fewer packets and >> see if the >> congestion clears. Then ramp them back up slowly until self- >> stabilized and >> no observable, persistent congestion is detected. >> >> In the case described below, there doesn't need to be protocol >> extensions to >> cover this issue. There are many ways system design choices can >> impact your >> implementation. >> >> -DWard >> >> On Jul 16, 2009, at 11:40 AM, Vishwas Manral wrote: >> >>> Hi A. Palanivelan, >>> >>> I agree with Nitin here. If BFD packets are not prioritized over >>> others, we need to fix that instead of any other changes. >>> >>> Thanks, >>> Vishwas >>> >>> On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur >>> wrote: >>>> >>>> Hi, >>>> >>>> I would think that if there are multiple things happening at >>>> the same >>>> time...then the system needs to prioritize >>>> BFD over other things in some way or offload bfd to some place >>>> that would >>>> prevent bfd from getting affected. >>>> >>>> Thanks >>>> Nitin >>>> >>>> On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" >>>> wrote: >>>> >>>> Hi Nitin, >>>> It is very true that BFD works well in planned restarts and we >>>> don't need >>>> GR extensions there. >>>> But, we have seen issues when bfd is working along with other time >>>> intensive, high priority events. >>>> >>>> In such a scenario, for GR, we are likely to hit bfd timer expiry >>>> which >>>> will be treated as a failure, thus bringing down the adjacencies >>>> (ISIS/OSPF). >>>> One such example is when there are scaled number of PPPoE >>>> sessions on a >>>> SP router that also has bfd enabled (with strict timers). >>>> >>>> This would mean looking for a workaround at the architecture >>>> level of >>>> your router to make this work. >>>> >>>> In fact, this sort of experience let me into writing this draft. >>>> Do revert back for more discussion. >>>> PS: sorry for that late reply. I had a recent road accident that >>>> put me >>>> off for a longer time. >>>> Regards, >>>> A.Palanivelan >>>> To: >, >>> bfd at >>>> ietf.org > >>>> >>>> ________________________________ >>>> >>>> Hi, >>>> >>>> You really do not need GR extensions to BFD to help with >>>> planned restart. There is enough text in draft-ietf-bfd-generic >>>> (Section 4.3.2.2) to help you accomplish what you want. >>>> >>>> At the top of my head, I can think of 2 ways: >>>> >>>> 1) Restarting router brings down BFD session with diag code of >>>> ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency >>>> on the peer. So the peer BFD session will go down but ISIS/OSPF >>>> will not treat it as an adjacency down event. >>>> >>>> 2) Restarting router increases the BFD session timer to XXX >>>> seconds (XXX > restart time). It can save some state locally >>>> to note this. After restart, the restarting router reads the local >>>> state and continues the BFD session from the UP state. >>>> >>>> Thanks >>>> Nitin >>>> >> >> From vishwas.ietf@gmail.com Mon Jul 20 17:01:53 2009 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 23BB53A6DBD for ; Mon, 20 Jul 2009 17:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 6KZQnEzY1ojE for ; Mon, 20 Jul 2009 17:01:52 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id E4AB83A6C07 for ; Mon, 20 Jul 2009 17:01:51 -0700 (PDT) Received: by yxe34 with SMTP id 34so4433169yxe.29 for ; Mon, 20 Jul 2009 17:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dwwc89xDKh+4N4kUfpii5XxO9iGW/6BZvWGNPTdGFzI=; b=h7wviU4UdBn3vxClgtDrpU+8PhmQ2QTJw63sFBxHgwHJlBgrhSemsc4rh/HIVCwCFj hVFd793ROmE143uXw7rTAIFri7a2YNCZtAWBFOR++/5Z6gKApNNehqBt1ojH8W7SiZap LjWSpXCBTfo0wez2DgpEJn3NJdJM14Mp7HoM8= 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=n6qUKTDgcSChfi17AyrQ/XvAWy5ofTefqnsjQSbopS55vZr8wT0zQzo7YcLkYBzix2 D+kuFhk+US/Nn7YiLcc4Q1+rBHrpbu4m4lTaKshxuH/5KI+cAH8Diub4kcK59XOFah5K eIwxIhDIYH/P0ymTedjd63bIqS5r13m3OrJk0= MIME-Version: 1.0 Received: by 10.150.97.20 with SMTP id u20mr6563588ybb.317.1248134493177; Mon, 20 Jul 2009 17:01:33 -0700 (PDT) In-Reply-To: References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> <00BFE893-FDB3-44E6-B10F-28BC5A795AC4@cisco.com> <77ead0ec0907201421t356d3838ge222266b93ba77b6@mail.gmail.com> Date: Mon, 20 Jul 2009 17:01:33 -0700 Message-ID: <77ead0ec0907201701w18ccd526qbb4612e592b4ee24@mail.gmail.com> Subject: Re: draft-palanivelan-bfd-v2-gr-02 From: Vishwas Manral To: David Ward Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Palanivelan A \(apvelan\)" , "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, 21 Jul 2009 00:01:53 -0000 Hi David, Thats correct, detection can only be done in the rx direction. But reaction can be to slow the rate of packet send/ receive or both. I was wondering what would be the suggested action? Thanks, Vishwas On Mon, Jul 20, 2009 at 3:33 PM, David Ward wrote: > > V - > > The method to detect persistent congestion will have enough rules for the > BFD packet loss over a stated interval. A system can only usefully detect= in > the rx direction. > > -DWard > > > On Jul 20, 2009, at 4:21 PM, Vishwas Manral wrote: > >> Hi David, >> >> Thanks for sharing the updates with us. >> >> So is the mechanism to do detect 'persistent congestion' also >> mentioned, or is that left out of scope. Also during congestion do we >> increase the 'Minimum receive interval' or the 'transmit interval' or >> both. So can the congestion assumed to be in both directions or only >> in the direction of the incoming flow? >> >> Thanks again, >> Vishwas >> >> On Thu, Jul 16, 2009 at 5:42 PM, David Ward wrote: >>> >>> One change to the BFD base spec as requested by the IESG is a congestio= n >>> control mechanism. We've come to conclusion with the transport, interne= t >>> and >>> routing ADs on the algorithm and you will see it in the last rev of the >>> base >>> spec. In a very short summary, if one can detect that there is persiste= nt >>> congestion then use the adaptive timers to send fewer packets and see i= f >>> the >>> congestion clears. Then ramp them back up slowly until self-stabilized >>> and >>> no observable, persistent congestion is detected. >>> >>> In the case described below, there doesn't need to be protocol extensio= ns >>> to >>> cover this issue. =A0There are many ways system design choices can impa= ct >>> your >>> implementation. >>> >>> -DWard >>> >>> On Jul 16, 2009, at 11:40 AM, Vishwas Manral wrote: >>> >>>> Hi A. Palanivelan, >>>> >>>> I agree with Nitin here. If BFD packets are not prioritized over >>>> others, we need to fix that instead of any other changes. >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> =A0 =A0I would think that if there are multiple things happening at t= he >>>>> same >>>>> time...then the system needs to prioritize >>>>> BFD over other things in some way or offload bfd to some place that >>>>> would >>>>> prevent bfd from getting affected. >>>>> >>>>> Thanks >>>>> Nitin >>>>> >>>>> On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" >>>>> wrote: >>>>> >>>>> Hi Nitin, >>>>> It is very true that BFD works well in planned restarts and we don't >>>>> need >>>>> GR extensions there. >>>>> But, we have seen issues when bfd is working along with other time >>>>> intensive, high priority events. >>>>> >>>>> In such a scenario, for GR, we are likely to hit bfd timer expiry whi= ch >>>>> will be treated as a failure, thus bringing down the adjacencies >>>>> (ISIS/OSPF). >>>>> One such example is when there are scaled number of PPPoE sessions on= a >>>>> SP router that also has bfd enabled (with strict timers). >>>>> >>>>> This would mean looking for a workaround at the architecture level of >>>>> your router to make this work. >>>>> >>>>> In fact, this sort of experience let me into writing this draft. >>>>> Do revert back for more discussion. >>>>> PS: sorry for that late reply. I had a recent road accident that put = me >>>>> off for a longer time. >>>>> Regards, >>>>> A.Palanivelan >>>>> To: >, >>>> ietf.org > >>>>> >>>>> ________________________________ >>>>> >>>>> Hi, >>>>> >>>>> =A0You really do not need GR extensions to BFD to help with >>>>> planned restart. There is enough text in draft-ietf-bfd-generic >>>>> (Section 4.3.2.2) to help you accomplish what you want. >>>>> >>>>> =A0At the top of my head, I can think of 2 ways: >>>>> >>>>> 1) Restarting router brings down BFD session with diag code of >>>>> =A0ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency >>>>> =A0on the peer. So the peer BFD session will go down but ISIS/OSPF >>>>> =A0will not treat it as an adjacency down event. >>>>> >>>>> 2) Restarting router increases the BFD session timer to XXX >>>>> =A0seconds (XXX > restart time). It can save some state locally >>>>> =A0to note this. After restart, the restarting router reads the local >>>>> =A0state and continues the BFD session from the UP state. >>>>> >>>>> Thanks >>>>> Nitin >>>>> >>> >>> > > From dward@cisco.com Mon Jul 20 17:12:12 2009 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 445CC3A6B60 for ; Mon, 20 Jul 2009 17:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] 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 mod+CjtCDZnt for ; Mon, 20 Jul 2009 17:12:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 17C4C3A6B16 for ; Mon, 20 Jul 2009 17:12:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,237,1246838400"; d="scan'208";a="350491797" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2009 00:11:41 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6L0Bfku028253; Mon, 20 Jul 2009 17:11:41 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6L0BfJS029821; Tue, 21 Jul 2009 00:11:41 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 20:11:41 -0400 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 20:11:39 -0400 Message-Id: From: David Ward To: Vishwas Manral In-Reply-To: <77ead0ec0907201701w18ccd526qbb4612e592b4ee24@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: draft-palanivelan-bfd-v2-gr-02 Date: Mon, 20 Jul 2009 19:11:37 -0500 References: <77ead0ec0907160940k5300d401i688dead2c22342f4@mail.gmail.com> <00BFE893-FDB3-44E6-B10F-28BC5A795AC4@cisco.com> <77ead0ec0907201421t356d3838ge222266b93ba77b6@mail.gmail.com> <77ead0ec0907201701w18ccd526qbb4612e592b4ee24@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 21 Jul 2009 00:11:41.0001 (UTC) FILETIME=[D2834390:01CA0997] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5336; t=1248135101; x=1248999101; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20draft-palanivelan-bfd-v2-gr-02 |Sender:=20; bh=5w4dZcUXjAU1983TK0fuJFu8WFzalbVAMq2gCSaZFww=; b=C2K5+Myp9ms6bvW35xDCm/ao9+Ej8ONudnpKwEvEpFR7vhL0A0Jy4geteS 1Y+5aY/T9IZHkywunZdljW/fc4Hq5cYlRi5MY6cOTNi4HIzbUjJGYj9iCaTn 41SgnzfXIO; Authentication-Results: sj-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "rtg-bfd@ietf.org" , "Palanivelan A \(apvelan\)" , David Ward 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, 21 Jul 2009 00:12:12 -0000 Could be both, directions are negotiated separately. What should be obvious is that it is impossible to tell what sort of congestion is being witnessed. Could be on the wire, could be a scheduler (if SW based implementation) ... either way, response is the same. -DWard On Jul 20, 2009, at 7:01 PM, Vishwas Manral wrote: > Hi David, > > Thats correct, detection can only be done in the rx direction. > > But reaction can be to slow the rate of packet send/ receive or both. > I was wondering what would be the suggested action? > > Thanks, > Vishwas > > On Mon, Jul 20, 2009 at 3:33 PM, David Ward wrote: >> >> V - >> >> The method to detect persistent congestion will have enough rules >> for the >> BFD packet loss over a stated interval. A system can only usefully >> detect in >> the rx direction. >> >> -DWard >> >> >> On Jul 20, 2009, at 4:21 PM, Vishwas Manral wrote: >> >>> Hi David, >>> >>> Thanks for sharing the updates with us. >>> >>> So is the mechanism to do detect 'persistent congestion' also >>> mentioned, or is that left out of scope. Also during congestion do >>> we >>> increase the 'Minimum receive interval' or the 'transmit interval' >>> or >>> both. So can the congestion assumed to be in both directions or only >>> in the direction of the incoming flow? >>> >>> Thanks again, >>> Vishwas >>> >>> On Thu, Jul 16, 2009 at 5:42 PM, David Ward wrote: >>>> >>>> One change to the BFD base spec as requested by the IESG is a >>>> congestion >>>> control mechanism. We've come to conclusion with the transport, >>>> internet >>>> and >>>> routing ADs on the algorithm and you will see it in the last rev >>>> of the >>>> base >>>> spec. In a very short summary, if one can detect that there is >>>> persistent >>>> congestion then use the adaptive timers to send fewer packets and >>>> see if >>>> the >>>> congestion clears. Then ramp them back up slowly until self- >>>> stabilized >>>> and >>>> no observable, persistent congestion is detected. >>>> >>>> In the case described below, there doesn't need to be protocol >>>> extensions >>>> to >>>> cover this issue. There are many ways system design choices can >>>> impact >>>> your >>>> implementation. >>>> >>>> -DWard >>>> >>>> On Jul 16, 2009, at 11:40 AM, Vishwas Manral wrote: >>>> >>>>> Hi A. Palanivelan, >>>>> >>>>> I agree with Nitin here. If BFD packets are not prioritized over >>>>> others, we need to fix that instead of any other changes. >>>>> >>>>> Thanks, >>>>> Vishwas >>>>> >>>>> On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur >>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I would think that if there are multiple things happening at >>>>>> the >>>>>> same >>>>>> time...then the system needs to prioritize >>>>>> BFD over other things in some way or offload bfd to some place >>>>>> that >>>>>> would >>>>>> prevent bfd from getting affected. >>>>>> >>>>>> Thanks >>>>>> Nitin >>>>>> >>>>>> On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" >>>>>> wrote: >>>>>> >>>>>> Hi Nitin, >>>>>> It is very true that BFD works well in planned restarts and we >>>>>> don't >>>>>> need >>>>>> GR extensions there. >>>>>> But, we have seen issues when bfd is working along with other >>>>>> time >>>>>> intensive, high priority events. >>>>>> >>>>>> In such a scenario, for GR, we are likely to hit bfd timer >>>>>> expiry which >>>>>> will be treated as a failure, thus bringing down the adjacencies >>>>>> (ISIS/OSPF). >>>>>> One such example is when there are scaled number of PPPoE >>>>>> sessions on a >>>>>> SP router that also has bfd enabled (with strict timers). >>>>>> >>>>>> This would mean looking for a workaround at the architecture >>>>>> level of >>>>>> your router to make this work. >>>>>> >>>>>> In fact, this sort of experience let me into writing this draft. >>>>>> Do revert back for more discussion. >>>>>> PS: sorry for that late reply. I had a recent road accident >>>>>> that put me >>>>>> off for a longer time. >>>>>> Regards, >>>>>> A.Palanivelan >>>>>> To: >, >>>>>> >>>>> ietf.org > >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> Hi, >>>>>> >>>>>> You really do not need GR extensions to BFD to help with >>>>>> planned restart. There is enough text in draft-ietf-bfd-generic >>>>>> (Section 4.3.2.2) to help you accomplish what you want. >>>>>> >>>>>> At the top of my head, I can think of 2 ways: >>>>>> >>>>>> 1) Restarting router brings down BFD session with diag code of >>>>>> ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency >>>>>> on the peer. So the peer BFD session will go down but ISIS/OSPF >>>>>> will not treat it as an adjacency down event. >>>>>> >>>>>> 2) Restarting router increases the BFD session timer to XXX >>>>>> seconds (XXX > restart time). It can save some state locally >>>>>> to note this. After restart, the restarting router reads the >>>>>> local >>>>>> state and continues the BFD session from the UP state. >>>>>> >>>>>> Thanks >>>>>> Nitin >>>>>> >>>> >>>> >> >>