[email protected]
[Top] [All Lists]

Re: Updated: draft-zinin-microloop-analysis-01.txt

Subject: Re: Updated: draft-zinin-microloop-analysis-01.txt
From: Alia Atlas
Date: Fri, 03 Jun 2005 17:13:06 -0400
At 02:43 PM 6/3/2005, Alex Zinin wrote:
Just like with the situation where the repairing router has type-C
next-hops, I needed to propose a way of dealing with it, but this certainly
needs to be discussed. From what I see on the list, Mike will check
his simulation models and let us know.

>     For situation 2 (an A/B or an A/C combination), the implementation:

>       1)   SHALL update the route with the new next-hops that satisfy the
>            safety condition without an additional delay

>       2)   SHALL add the remaining new next-hops after DELAY_TYPEB.

SB>> maybe clarify type B is NOT used, although, there seems to
SB>> be no protocol reason why use type B cannot be used.

I'm not sure I understand what you mean here.
Safe but not new primary neighbors (type B) could be used during the
transition period. This is expressing a policy that they will not be; it
would be safe to use them.
> ------------------------

> 3.3 IP Fast Reroute Considerations

>     If the router implements [IPFRR] and performs local failure repair,
>     procedures describes in this document still need to be applied in
>     order to prevent micro-loops while reconverging on the new topology.

OK, what the reason I put this text there is to define exactly how PLSNs
work with Basic FRR, if IPFRR is used.
I can add some text in the intro to say that a repair mechanism is
desirable and why.

Alia, Stewart, I don't think the text disallows future repair techniques,
but let me know, guys, how you think the text could be improved.
How about just changing where you have "procedures describes in this
document ...." to "a controlled convergence mechanism such as that
described in the procedures in this document"?

Rtgwg mailing list
[email protected]

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