[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: Stewart Bryant
Date: Mon, 20 Jun 2005 11:00:01 +0100
I agree with Mike, 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.

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

- Stewart


mike shand wrote:

At 21:09 14/06/2005, Bill Fenner wrote:

There's certainly been discussion on the technical content, but
let's look for consensus on the meta-issue: should this document
be a rtgwg work item?  Let's make this a 1 week WG call for comments;
both for and against (well, we don't *need* any against, but if they're
there I want to hear them!).  I'll evaluate WG consensus on June 22.

Thanks,
  Bill

Yes, I think it should be WG document. It plays nicely with the "Basic" IPFFR solution. However, I would not like this to prevent us working on methods which give complete prevention of loops for use with IPFRR mechanisms which give complete repair.
On the complexity front, I think we can probably omit the type B
destinations (treating them as type Cs). This will give slightly worse
performance (but my simulations indicate this is quite a small change),
but will allow the convergence to be complete after 1 rather than 2
delay cycles, and will avoid the need to change a FIB entry for a
destination twice. This is probably a tradeoff worth making (since
neither gives complete protection).
        Mike
_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg


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

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