[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: mike shand
Date: Wed, 15 Jun 2005 08:00:57 +0100
At 22:09 14/06/2005, Curtis Villamizar wrote:

In message <[email protected]>
Bill Fenner writes:
> >I will ask Bill to check WG consensus on taking this doc as a WG item.
> >Please read and send your comments to the list.
> 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


It seems to me that the whole IPFRR effort is way more complicated
than what it set out to replace, RSVP-TE FRR, when the justification
for doing IPFRR was to avoid complexity.  Regardless, here we are.
I have a certain sympathy with that position. However, remember that the
microloop prevention came out of addressing a problem which was not
addressed, and which remains a problem, with MPLS-TE when used with LDP.
i.e. the loop prevention is applicable to that environment as well.

My initial thought was that Alex's internet draft covered a topic that
needed to be covered.  As the safety conditions were "fine tuned", the
draft has become a bit more complicated in that you now have to
determine if the router is Type A, B, or C with respect to a given
That has always been the case since Alex first presented his draft. What we
have been discussing recently is the relative merits of adopting a more
conservative safety criteria in an attempt to avoid multi-hop loops at the
expense of reducing the overall level of protection against any loops. My
finding suggest that sticking with the existing safety criterion is
actually more effective.
 A prerequisite to accepting this draft should be documenting
the existance of an efficient algorithm that makes this determination
for the entire set of prefixes.  The algorithm must also be
unencumbered by intellectual property restrictions.

In the mean time, can we let the technical discussion settle down and
have someone summarize what the microloop loop threat remains when the
mechanism Alex is proposing is used?
The difficulty with that is that a single metric does not give a good
picture of what is going on. We have talked about
percentage of failures which generate no loops
percentage of the failures which without protection would produce loops which still produce loops wen protected
the same for percentage of destinations

the same for percentage of source destination pairs.

All the above for node failure as opposed to link failure.

The best visualization I have come up with is the diagrams I have presented at IETF showing a histogram across all the links of percentage of source destination pairs looped using no protection, PLSN as in the draft and PLSN, but treating type B as type C.

 I'm not sure what changes if any
have come out of the discussion since the volume of messages has
obscured any conclusion of the discussion for me anyway.
I think the bottom line of the recent discussion is that the proposed
change to use a stricter criterion for networks containing asymmetric costs
is counter-productive.


Rtgwg mailing list
[email protected]
Rtgwg mailing list
[email protected]

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