Alex Zinin wrote:
Do you mean you agree with making this a WG document?
It should become a WG item, but before we take it to
the IESG to become an RFC, we need to establish it's
context and determine whether it should be published
stand-alone, or integrated into another protocol.
The plan is to use the applicability statement to establish the context for
both Basic IP FRR and the micro-loop prevention mechanism the WG ends up
specifying, and how they relate to each other. I'm not sure what "another"
protocol you mean.
another protocol == micro-loop prevention mechanism the WG ends up specifying
When we understand those requirements, we will better understand
the context of this partial solution to the microloop problem.
I think we understand those.
That is not clear. For example, we do not seem to have any traceable
input from the OPs area on what there requirements are WRT the use
of controlled convergence. Are they looking for "a bit better" or
"a fully managed transition"? Do we have any traceable requirements
from MPLS WG WRT convergence in LDP networks?
Note that there is no procedural step that requires this WG to receive
formal requirements from OPS area or MPLS WG for the mechanisms its working
on. Now, is soliciting those a good idea? Absolutely. To start with, there
are operators on this mailing list. Next, the plan is to request reviews
from other WGs (OSPF, ISIS, MPLS, etc.) once the next revs of the specs are
Regarding what "they are looking for". Let's keep in mind that we have a
very specific task at hand here: IP Fast Reroute, which is the primary
context the micro-loop solutions need to be considered in.
The overriding task at hand is "to make the Internet work better", and
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.
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
I don't see why or how it would. From the DT recommendation text:
Another positive aspect of the PLSN method is that it does not
preclude later extensions to improve coverage and prevent loops for
left out by PLSN by employing other mechanisms for them (e.g. tunnel-based or
I think that the issue is that I see PLSN as an enhancement to some
other method, rather than a method in it's own right.
Very well. I respectfully disagree with you, however--within the IPFRR
context, I believe PLSN and Basic FRR can give reasonable results.
... and I am questioning whether the IPFRR context is the right context
to make the call. Let's at least ask the other Areas if convergence
control is a facility that they need, and if so, what are their
I don't understand what you mean here.
Start with the requirements from IPFRR, MPLS FRR and OPS.
Design a solution.
Use PLSN to make that solution go faster by integrating it
into that solution.
In general, I don't see how using PLSN with IPFRR prevents applying other
methods to PLSN-unprotected destinations. The end result is the same.
Except in your proposal we'll have to delay progress with IPFRR until
(presumably) a bigger problem is solved, which I don't believe is
More specifically, how do you think MPLS and OPS reqs will be different,
They may look for greater coverage on day one.
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.
Rtgwg mailing list