Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)

[Alvaro Retana <[e-mail]>]

On Wed, Oct 11, 2017 at 5:07 AM, <[e-mail]> wrote:

Stephane:

Hi!

...

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 5.1. (Definitions) refers to a couple of “existing IGP timers”.  I
> understand the concepts, but can you please reference the IGP documents
> where these timers are defined?  I quickly checked rfc2328 and couldn’t
> find a specific place that talked about LSP_GEN_TIMER (or LSA, of course!),
> or a similar concept.  SPF_DELAY seems to be introduced by
> I-D.ietf-rtgwg-backoff-algo.  Given that the rest of Section 5.
> (Specification) is built on these “existing IGP timers”, I think that the
> references should be Normative.
>
> [SLI] ISIS does have the minimumLSPGenerationInterval defined in the ISO
> specification. I will add it. For OSPF, I do not see the equivalent in the
> base spec. I will check with Acee if he knows some references or if it's
> purely local features that have been implemented.
>

This is the definition from 10589:

minimumLSPGenerationInterval – This is the minimum time interval between
generation of Link State PDUs. A source Intermediate system shall wait at
least this long before re-generating one of its own Link State PDUs.


That is not the same as LSP_GEN_TIMER.

I get the impression that the only place where  that documents it might be
I-D.ietf-rtgwg-backoff-algo.



> Note also that the description in Section 5.2. (Current IGP reactions) is
> described (in 5.3) as the “standard IP convergence” and carries a “MUST”
> associated with it.  It was mentioned (in 5.1) that the timers in question
> are “often associated with a damping mechanism”, which is not part of the
> base IGP specifications.
>
> [SLI] I agree with your point. I think that the "standard" word is badly
> used it and "regular" may be more appropriate.
> The behavior defined in 5.2 cannot be defined as a standard, as it clearly
> depends on the implementation and additional timers may be involved.
> My proposal is to:
> - change the word "standard" to "regular" in section 5.3
> - change the title of Section 5.2 to "Regular IGP reaction" to accommodate
> the change in 5.3
> - In 5.2, modify slightly the text as follows:
> " Upon a change of the status of an adjacency/link, the regular IGP
> convergence
>    behavior of the router advertising the event involves the following
> main steps: "
>
> It's important to keep the "MUST" in section 5.3, as applying the delay
> timer to complex outages is dangerous and may lead to side effects.
>

Yes, the changes are fine.  The MUST being there is needed (I agree) --
that is what makes the reference needed to be Normative.


>
>
>
>
> I’m putting this comment in as a DISCUSS given that understanding the
> definitions (and having then Normative references) is necessary for the
> implementation of the mechanism described.  I think it should be easy to
> resolve by just adding the appropriate references.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ...
> (2) Section 5.4. (Local delay for link down) specifies that “update of the
> RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER msecs.
> Otherwise, the RIB and FIB SHOULD be updated immediately.”  When would
> ULOOP_DELAY_DOWN_TIMER not be applied?
> [SLI] The text states " If the
>       condition of a single local link-down event has been met ". The
> "otherwise" is linked to this statement. This means that the FIB/RIB SHOULD
> be updated immediately when this condition is not met.
>

Sorry, that question was for the first "SHOULD":

In "update of the RIB and the FIB SHOULD be delayed for
ULOOP_DELAY_DOWN_TIMER msecs", when would you not delay?  Why is that not a
"MUST"?


> (2)Along the same lines, if there’s no delay mentioned in Step 5 of 5.3,
> when would the RIB/FIB not be updated immediately?  IOW, why are these
> “SHOULDs” not “MUSTs”?
> [SLI] Do you refer to 5.2 (and not 5.3) as there is no Step 5 in 5.3. In
> 5.2, the RIB/FIB are updated immediately after the SPF computation.
>

Yes, 5.2.

Right, 5.2 says that the RIB/FIB are updated immediately, but the text in
5.4 only says that it "SHOULD" -- why is that not a "MUST"?  Are there
cases when it wouldn't?


Thanks!

Alvaro.