Subject: Re: draft-palanivelan-bfd-v2-gr-02

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Thu, 16 Jul 2009 15:42:44 +0530

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: <apvelan at cisco.com <mailto:[email-masked]> >, <rtg-bfd at
ietf.org <mailto:[email-masked]> >

*	Subject: Re: draft-palanivelan-bfd-v2-gr-01
*	From: Nitin Bahadur <nitinb at juniper.net
<mailto:[email-masked]> >
*	Date: Tue, 3 Feb 2009 16:49:12 -0800
*	Delivered-to: rtg-bfd at core3.amsl.com
<mailto:[email-masked]> 
*	List-archive: <https://www.ietf.org/mailman/private/rtg-bfd>
*	List-help: <mailto:[email-masked]?subject=help>
*	List-id: "RTG Area: Bidirectional Forwarding Detection DT"
<rtg-bfd.ietf.org>
*	List-post: <mailto:[email-masked]>
*	List-subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>,
<mailto:[email-masked]?subject=subscribe>
*	List-unsubscribe:
<https://www.ietf.org/mailman/listinfo/rtg-bfd>,
<mailto:[email-masked]?subject=unsubscribe>
*	Thread-index: AcmGYmVThhxLBgEuTGCCrADrG/c6fQ==
*	Thread-topic: Re: draft-palanivelan-bfd-v2-gr-01

________________________________

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