[email protected]
[Top] [All Lists]

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

Subject: Re: Updated: draft-zinin-microloop-analysis-01.txt
From: Alex Zinin
Date: Fri, 3 Jun 2005 11:43:57 -0700

I'll revise the text based on the editorial comments and the discussion
on the list. Less trivia comments below:

> Some comments on: draft-zinin-microloop-analysis-01.txt

>     Routers SHOULD use the symmetric-link safety condition by default,
>     MAY attempt to dynamically determine the method that needs to be
>     applied based on the topological information from the routing

SB>> I think that we need to discuss which algorithm should
SB>> be the default. Given that many networks that are thought
SB>> to be symmetric turn out to be asymmetric, it's not clear
SB>> which we should choose and why.

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.

> ------------------------

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

SB>> This is stricter than it should be. Say we implement basic [IPFRR]
SB>> AND some other enhanced mechanism. We may wish to use some other
SB>> mechanim in place of this.

Stewart, what do you see as too strict here? How do you think the text
should be changed?

AA>> I think that the intention should be to say that PLSN is useful to
AA>> avoid micro-loops during re-convergence and this benefit is not
AA>> provided simply by using basic [IPFRR] or another repair mechanism.
AA>> Both a repair mechanism and a convergence control mechanism are
AA>> desirable. I do think it would be useful to specify the
AA>> risks/undesirability of using PLSN without a repair mechanism when the
AA>> topology change includes failures. I do agree with Stewart that the
AA>> phrasing should consider the possibility of future techniques being
AA>> introduced.

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.

>     The following equations define the relationship between the constants
>     that needs to be maintained in order for the mechanism described here
>     to provide desireable results:

>      DELAY_SPF > update-propagation-time

>      DELAY_STABLE > DELAY_TYPEB > DELAY_TYPEC > fault-propagation-time

SB>> I deleted soem of the text from this edit. Did you say that
SB>> FIB updates MUST be completed by expiry of appropriate timer?

The definition of fault-propagation-time includes the FIB update time.

> ------------------------------

>     The implementations SHOULD use the following default values for the
>     architectural constants:

>          Constant                   Default val
>         ----------------------------------------
>          DELAY_SPF                   500 msec
>          DELAY_TYPEC                   2 sec
>          DELAY_TYPEB                   4 sec
>          DELAY_STABLE                 10 sec

SB>> On what basis? I imagine that you pulled these out of a hat,
SB>> and I suspect that they are as good values, but I think
SB>> that you need to say that is what you did.

As we discussed this before, yes, these are the default times pulled out of
a hat. The text actually describes that at certain length:

>    While correctness and effectiveness of the algorithm described here
>    does not depend on the actual values assigned to the architectural
>    constants, it does depend on the relationship between them, and the
>    assumption that all routers in the same network use the same values.
>    To satisfy these constrains, and yet allow these delays to be
>    decreased as implementations continue to improve towards faster con-
>    vergence, this document defines the architectural constants as con-
>    figurable, specifies the required relationship between the values,
>    and the default values that should be used by the implementations.
>    The following equations define the relationship between the constants
>    that needs to be maintained in order for the mechanism described here
>    to provide desireable results:

Let me know what you think should be added.

> 5 Security Considerations
SB>> Isn't there a threat in which some vulnerable link is failed
SB>> causing extended C-C outage?

I don't think so. The DELAY_TYPE? values are the same O() as SPF hold-downs
in the majority of deployed networks.


Rtgwg mailing list
[email protected]

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