RE: discussion on fast notification work

[András Császár <[e-mail]>]

Hello Curtis, 

> We don't want a
> protocol fix that addresses a bad implementation of a perfectly good
> protocol.

Please note we are not trying to develop a protocol fix.
Currently there exist not standard protocol for
- IPFRR
- with 100% failure coverage

There are proposals only. So there is nothing to fix.

Note that IPFRR-FN has no intention to fix/improve OSPF/ISIS routing convergence. Instead, we acknowledge that there are practical reasons why IGPs typically do not provide fail-over times below a few hundred milliseconds. But if sub-50ms fail-over is really needed (which could actually be another thread for debate IMHO), then something else is needed.

We are almost finishing the new drafts, but it is unlikely we can submit them much earlier before Monday's cut-off.

András


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Curtis Villamizar
> Sent: 2011. július 8. 1:19
> To: Jeff Tantsura
> Cc: [e-mail]
> Subject: Re: discussion on fast notification work 
> 
> 
> I agree with John that there doesn't seem to be a problem to solve.
> 
> To add to that.
> 
> In this case there seem to be consensus that this was a bad idea.  If
> the authors want to change that consensus, a draft should come well
> ahead of the meeting with discussion on the list, and only then if
> there is interest, should be spend meeting time on this.
> 
> For example, on the list we can discuss what vendor equipment was used
> in the networks that were prototyped/measured.  We don't want a
> protocol fix that addresses a bad implementation of a perfectly good
> protocol.  I prefer draft first, well in advance of the meeting, then
> consider a time slot allocation after discussion on list.
> 
> [ begin aside
> 
> The issue is whether it is possible to keep the flooding latency low
> relative to geographic delay and detection time.  A somewhat worst
> case flooding delay in a good implementation consists of 1) receive
> packet on line card, check if it is a known change, 2) send it to
> another processor to verify if it is known, 3) receive it agains and
> recheck, 4) send it again to line cards, 5) receive it and send it on
> the line interface.  Some implementations multicast from the receiving
> node, yielding only one internal hop, for two context switches total.
> 
> Even absent of geographic delay, detection time is order 10 msec.  If
> we assume a context switch time of 1 msec even receiving a packet
> three times within the same node adds on the order of 3 msec per hop.
> 
> In a good implementiation, this processing is done on the line cards
> which have little else to do other than react to low effort near real
> time requirements such as protection and flooding and installing new
> state at a slightly lower priority (and with good CPU starvation
> prevention in the scheduling).  If the line card processor is doing
> real time work and there is a desire to reduce latency, most cards
> today can support a change to the clock interrupt from a 1000 Hz clock
> to something a bit faster.  The down side is increasing the amount of
> time spent in the RTC interrupt code.
> 
> In a bad implementation there is a chance that a CPU delays flooding
> while waiting for an SPF or for some high CPU user link BGP to finish
> up some increment of work.  Then the delays can be quite long.
> 
> One advantage of flooding is that after a fault the flooding does not
> rely on assumptions about the remaining topology.  Multiple simultaous
> faults due to failure of a shared resource can and often do occur.
> Any mechanism that relys on forwarding or relies on source routing
> through a best guess at what links remain will fail to deliver
> notifications in such a case.  In that case we are back to the
> flooding delay anyway, so might as well work on keeping that short.
> 
> Maybe on the list the authors can describe the motivation, the target
> flooding or notification delay, and how the shortcomings discussed
> previously are addressed.
> 
> end aside ]
> 
> Curtis
> 
> In message 
> <[e-mail]
> .ericsson.se>
> Jeff Tantsura writes:
> >  
> > Hi Alia/John,
> >  
> > Thanks for your comments.
> >  
> > We have been listening very carefully and have taken all the critic
> > rather seriously.
> >  
> > We have changed the way we distribute FNs, added authentication and
> > prototyped/measured convergence times in networks of different
> > diameters.  We have also added some additional clients (protocols to
> > use FN)
> >  
> > Updated draft will be published soon.
> >  
> > We would really like to present our work.
> >  
> > Thanks! 
> >  
> > Regards,
> > Jeff  
> >  
> > -----Original Message-----
> > From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of John E Drake
> > Sent: Wednesday, July 06, 2011 14:54
> > To: Alia Atlas; [e-mail]
> > Subject: RE: discussion on fast notification work
> >  
> > Alia,
> >  
> > Is it okay for me to say that I think that this is a really bad idea
> > and that I was glad that interest in it had waned?
> >  
> > Thanks,
> >  
> > John
> >  
> > Sent from my iPhone
> >  
> >  
> > > -----Original Message-----
> > > From: [e-mail] 
> [mailto:[e-mail]] On Behalf
> > > Of Alia Atlas
> > > Sent: Wednesday, July 06, 2011 1:57 PM
> > > To: [e-mail]
> > > Subject: discussion on fast notification work
> > > 
> > > The last 2 IETFs, we have had discussions about the idea of fast
> > > notification, as described in
> > > draft-lu-fast-notification-framework, 
> draft-lu-fn-transport-00, and
> > > draft-csaszar-ipfrr-fn-00.
> > > 
> > > Since then, I have not seen substantial discussion or 
> interest on the
> > > mailing list.  If you are
> > > interested in this work, have questions about it, or 
> would like to see
> > > RTGWG continue to discuss it,
> > > please send email to this mailing list.  I'd like to see this
> > > conversation happening here before IETF.
> > > 
> > > Thanks,
> > > Alia
> _______________________________________________
> rtgwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtgwg
>