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

From: Stewart Bryant <[email-masked]>
Date: Tue, 05 Jul 2005 10:35:25 +0100

Alex Zinin wrote:

> Stewart,
> 
> 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
>>conservative approach.
> 
> 
>>I think that we should start by understanding the wider need
>>for this technology, as outlined in:
> 
> 
>>http://www.ietf.org/internet-drafts/draft-bryant-shand-lf-applicability-00.txt
> 
> 
>>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
>>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.

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

- Stewart

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: Alex Zinin <[email-masked]>
Date: Fri, 8 Jul 2005 14:41:36 -0700

Stewart,

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

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

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.

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

> Use PLSN to make that solution go faster by integrating it

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

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
foresee?

--
Alex

---

From: Bill Fenner <[email-masked]>
Date: Fri, 8 Jul 2005 21:52:07 -0400

>let's look for consensus on the meta-issue: should this document
>be a rtgwg work item? ...
>I'll evaluate WG consensus on June 22.

Boy, does time fly.  After a burst of discussion, I see several
proponents of it becoming a WG document, and none against.  It's
clear that the document needs some work, at least in some peoples'
opinion, and that we should be careful about scoping this against
future work -- but that's why it's a WG document, to get it to
reflect the WG's work.

  Bill

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Jul 2005 15:59:25 +0100

Bill

Whilst the draft should become a WG draft and hence become the
product of the WG, it is unclear whether it should be published
as an RFC, or whether it should be incorporated into the text
of an RFC describing a more capable mechism.

-Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Jul 2005 18:26:15 +0100

> specifying, and how they relate to each other. I'm not sure what "another"

another protocol == micro-loop prevention mechanism the WG ends up specifying

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

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

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

- Stewart

---

From: Alex Zinin <[email-masked]>
Date: Mon, 11 Jul 2005 11:38:20 -0700

Stewart,

It seems this part below is the core of your argument:

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

> and

Always a good idea.

> Let's at least ask the other Areas if convergence

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

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

-- 
Alex
http://www.psg.com/~zinin

---

From: Alex Zinin <[email-masked]>
Date: Thu, 14 Jul 2005 12:37:36 -0700

I've resubmitted draft-zinin-microloop-analysis-01.txt as is but with
 the draft-ietf-rtgwg prefix in the name. All corrections to reflect
 the discussion on the list will go to -01.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 14 Jul 2005 12:39:08 -0700

Mike's simulations have shown that though applying the stricter
 loop-freeness condition in asymmetric-cost topologies prevents multi-hop
 loops, it reduces general coverage and hence leads to more type-C chains
 that results in more 2-hop loops.

 I suggest that we remove the asymmetric condition from the document and
 always use the original (symmetric) one.

-- 
Alex