RE: draft-palanivelan-bfd-v2-gr-02

[Satyam Sinha <[e-mail]>]

Hi,

As Nitin explained, the base draft can support this functionality. If we add the new "easier" ways, 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 standard.

Regards,

Satyam  

> Subject: RE: draft-palanivelan-bfd-v2-gr-02
> Date: Thu, 16 Jul 2009 22:22:39 +0530
> From: [e-mail]
> To: [e-mail]; [e-mail]
> CC: [e-mail]
> 
> Hi Vishwas,
> 
> Like I have explained in section 3.2, a SP responding to a session renewal 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 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:[e-mail]] 
> Sent: Thursday, July 16, 2009 10:11 PM
> To: Nitin Bahadur
> Cc: Palanivelan A (apvelan); [e-mail]
> 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<[e-mail]> 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)" <[e-mail]> 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: <apvelan at cisco.com <mailto:[e-mail]> >, <rtg-bfd at ietf.org <mailto:[e-mail]> >
> >
> > ________________________________
> >
> > 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
> >

_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits. 
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009