Re: discussion on fast notification work

[Curtis Villamizar <[e-mail]>]

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]>
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