Curtis,
At 06:40 PM 6/15/2005, Curtis Villamizar wrote:
> >My initial thought was that Alex's internet draft covered a topic that
> >needed to be covered. As the safety conditions were "fine tuned", the
> >draft has become a bit more complicated in that you now have to
> >determine if the router is Type A, B, or C with respect to a given
> >prefix.
>
> That has always been the case since Alex first presented his draft.
What we
> have been discussing recently is the relative merits of adopting a more
> conservative safety criteria in an attempt to avoid multihop loops at the
> expense of reducing the overall level of protection against any loops. My
> finding suggest that sticking with the existing safety criterion is
> actually more effective.
That was not the case when the draft was privately circulated prior to
initially being submitted or presented. Originally the delay was
proportional to the distance from the failure. Distance from the
failure is quite easy to determine and does not vary per prefix. Type
A, B, or C varies per prefix and I'm not sure that there is an easy
way to determine it.
I think you are remembering the Ordered FIB installation approach. You
might take a look at
http://psg.com/~zinin/ietf/rtgwg/IETF61rtgwguloopprev.ppt, which
describes the different approaches considered.
> > A prerequisite to accepting this draft should be documenting
> >the existance of an efficient algorithm that makes this determination
> >for the entire set of prefixes. The algorithm must also be
> >unencumbered by intellectual property restrictions.
You didn't comment on this.
The information required is the same as for LFA. This simply requires
remembering the neighbors that were loopfree in the previous topology. I
think that this is actually a nice complement to LFA because, while it does
require another decision per prefix, it doesn't require additional SPFs or
equivs to be run.
Alia
Other than some concern about whether an efficient unencumbered
algorithm to determine Type A, B, or C, I have no objections to this
being accepted as a WG document. If there is no efficient algorithm
or no efficient unencumbered algorithm, then there is reason to at
least simplify this, possibly back to the delay based on distance
approximation that Alex first considered (but not to the WG).
Curtis
_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg
