[email protected]
[Top] [All Lists]

Re: WG Item?: draft-zinin-microloop-analysis-01.txt

Subject: Re: WG Item?: draft-zinin-microloop-analysis-01.txt
From: Alex Zinin
Date: Fri, 8 Jul 2005 14:41:36 -0700

>> 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.

>>>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.

>>>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,
>> 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 
>> destinations
>>    left out by PLSN by employing other mechanisms for them (e.g. 
>> tunnel-based or
>>    FIB ordering).

> 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.

>> 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,
and what other solutions that haven't been discussed by the DT do you


Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>