Re: [OSPF] FYI on draft-kini-ospf-fast-notification-01

Dear Authors,
please kindly consider my comments and questions below (though some could be
duplicates of already received):

   - section 4.3 Fast Flooding has reliability as first requirement. I've
   noticed that Section 4 Operation doesn't list Auto-discovery or Registration
   as part of Fast Failure Notification mechanism. Is it assumed that an IGP
   will build the list of addressees, participants of the Fast Notification?
   - how would node(s) that detected a failure would achieve reliable
   transport of notifications?
   - if full set of destinations is not known what indicates that
   notification reached all participants?
   - when requiring reliability of notification transport you consider
   "notification received" or "notification processed"
   - section 5.2 I believe that in the scenario you present not only node B
   will flood notifications, but node A will flood them as well. That would not
   change convergence time if only to improve it in some scenarios but it might
   be worth to mention that notifications will be generated by both ends of a
   failed link.


Regards,
Greg

On Tue, Mar 29, 2011 at 8:49 AM, Sriganesh Kini <sriganesh.kini@ericsson.com
> wrote:

>  Just an FYI to the list
>
> This draft http://tools.ietf.org/html/draft-kini-ospf-fast-notification-01 was
> presented at the OSPF WG mtg today.
>
> Thanks for the comments/questions at the mic. We will submit a new version
> addressing the comments.
>
> Note that the other drafts related to Fast Notification (FN) are
> draft-lu-fn-transport and draft-lu-fast-notification-framework. These were
> presented in RTGWG.
>
> Thanks
>
> - Sri
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>