It seems this part below is the core of your argument:
> ... and I am questioning whether the IPFRR context is the right context
> to make the call.
There may be other "right" contexts for micro-loop prevention. This,
however, doesn't make IPFRR the wrong one, and given that this is what this
WG has on its charter to deliver, I would argue that this is the primary
one here and now.
> The overriding task at hand is "to make the Internet work better",
Indeed, and the way the IETF does it is by solving very specific problems
like IPFRR, and we've been quite successful approaching complex problems
> it's not clear that the members of the IETF outside RTGWG are generally
> aware of the capability that we have developed. That is why I think
> that their view is important at this stage.
Always a good idea.
> Let's at least ask the other Areas if convergence
> control is a facility that they need, and if so, what are their
We will ask for feedback. We will bring it to this WG. However, we will not
ask for requirements documents or stop working on IPFRR mechanisms waiting
>>> and what other solutions that haven't been discussed by the DT do you
>> There are other solutions, we can talk about that at the next IETF.
I would urge you to make your thoughts available to the WG in the form of
an I-D as soon as possible. The DT you were part of already spent a lot of
time exploring multiple algorithm, and it wasn't easy. As I'm sure you will
agree with me, we could spend at least another year or two researching this
problem space, however, this is not what we do here. We need a very
pragmatic, engineering-ready solution here, and the DT has gone a long way
doing that. Resetting the process at this stage would definitely be
Rtgwg mailing list