I agree with Mike, although I would suggest that we take a more
I think that we should start by understanding the wider need
for this technology, as outlined in:
which demonstrates the applicability of the work to the MPLS WG
and to the OPS area.
When we understand those requirements, we will better understand
the context of this partial solution to the microloop problem.
My concerns in moving this to a WG item are two fold:
Firstly that adoption of this may inhibit work on one of the more
complete solutions, and secondly that although safe neighbours
clearly complements some of the other solutions, it would be
better to design it as an enhancement - to ensure a good
match - rather than to fit the rest of the solution round safe
mike shand wrote:
At 21:09 14/06/2005, Bill Fenner wrote:
There's certainly been discussion on the technical content, but
let's look for consensus on the meta-issue: should this document
be a rtgwg work item? Let's make this a 1 week WG call for comments;
both for and against (well, we don't *need* any against, but if they're
there I want to hear them!). I'll evaluate WG consensus on June 22.
Yes, I think it should be WG document. It plays nicely with the "Basic"
IPFFR solution. However, I would not like this to prevent us working on
methods which give complete prevention of loops for use with IPFRR
mechanisms which give complete repair.
On the complexity front, I think we can probably omit the type B
destinations (treating them as type Cs). This will give slightly worse
performance (but my simulations indicate this is quite a small change),
but will allow the convergence to be complete after 1 rather than 2
delay cycles, and will avoid the need to change a FIB entry for a
destination twice. This is probably a tradeoff worth making (since
neither gives complete protection).
Rtgwg mailing list
Rtgwg mailing list