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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
"Bhatia, Manav (Manav)" writes:
>  
>  
> > There is no question that you *can* design and/or code things badly.
> > There was work done by Packet Designs and Qwest a while back and
> > reported in NANOG.  After this work, a major router vendor's
> > implementation was optimized and a lot of delays were removed.  A big
> > mistake they were making is SPF and route install first and then
> > reflood.  It is better to get the word out that there is a problem.
>  
> I believe RFC 2328 is quite clear that LSAs should be flooded before
> "recalculating the routing table structure", so I am quite surprised
> that there were implementations that were doing otherwise. Thus I
> don't think anybody on this list seriously believes that this is an
> issue that folks are trying to solve. I believe the idea is quite
> simple - Flooding a changed LSA in HW (data plane) is faster than
> doing it in SW (not matter how optimized the latter is) or your
> control plane.
>  
> Lets at least look at the proposed solution and see if its worth
> considering. Who knows the discussion might lead us to something
> better that we may want to use.
>  
> Also note that I am not the author or in any way related to the draft!
> :)
>  
> Cheers, Manav


We have plenty of junk internet-drafts in IETF.  One or two less would
be better.  If it is not solving a real world problem then we should
get rid of it.  First we have to agree that there is a requirement.

draft-kini-ospf-fast-notification-01.txt calls for multicast, and
cites draft-lu-fast-notification-framework-00.txt for "transporting
the message encoding", but the latter makes no mention of multicast.

If multicast is used, a multicast routing protocol is needed.  A
multicast tree can have transient loops.  The last thing we need to
add to OSPF is a new control plane transient loop creation capability.
At least flooding is guarenteed to never loop.

When a fault occurs in a multicast tree, the tree must converge before
any other fault is reliably reported using multicast.  Multiple faults
are common.  Most are covered in protocols such as RSVP-TE that
support SRLG (but many are not even covered by SRLG).

This work is half thought out and it doesn't address a real problem so
I support telling the authors that it has no place in the OSPF WG.

Curtis