Alex Zinin wrote:
I don't quite understand where you're coming from.
I agree with Mike,
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.
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.
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?
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.
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
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.
Rtgwg mailing list