[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: Curtis Villamizar
Date: Wed, 15 Jun 2005 18:40:47 -0400
In message <[email protected]>
mike shand writes:
> 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
> >
> >
> >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.

Good point.

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

That was not the case when the draft was privately circulated prior to
initially being submitted or presented.  Originally the delay was
proportional to the distance from the failure.  Distance from the
failure is quite easy to determine and does not vary per prefix.  Type
A, B, or C varies per prefix and I'm not sure that there is an easy
way to determine it.

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

You didn't comment on this.

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

Thanks for the summary.

>          Mike

Other than some concern about whether an efficient unencumbered
algorithm to determine Type A, B, or C, I have no objections to this
being accepted as a WG document.  If there is no efficient algorithm
or no efficient unencumbered algorithm, then there is reason to at
least simplify this, possibly back to the delay based on distance
approximation that Alex first considered (but not to the WG).


Rtgwg mailing list
[email protected]

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