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

[Alvaro Retana <[e-mail]>]

On Thu, Oct 12, 2017 at 2:47 AM, <[e-mail]> wrote:

Hi!

The minimumLSPGenerationInterval is IMO the LSP_GEN_TIMER we are
> describing. It controls the pacing of the local LSP generation. In ISO
> 10589, it is a fixed timer value while now implementations are often using
> a damping mechanism associated with this timer rather than a fixed value.
>
>
>
> The MinLSInterval seems to be the equivalent in OSPF (I’m not an expert in
> OSPF, but Acee pointed this one to me). Again the backoff/damping is not
> defined as a standard. There is a BCP RFC 4222 but it does seem to address
> the MinLSInterval backoff.
>
>
>
> The I-D.ietf-rtgwg-backoff-algo only controls the SPF delay, not the
> LSP_GEN_TIMER.
>
>
>
> Do you agree ?
>

No, I don't agree that LSP_GEN_TIMER is the same as
minimumLSPGenerationInterval
or MinLSInterval.

LSP_GEN_TIMER is described to "batch multiple local events in one single
local LSP/LSA update", but both minimumLSPGenerationInterval/MinLSInterval
are about regeneration of LSP/LSAs.  IOW, the description in 5.2

"2.  The IGP processes the notification and postpones the reaction for
       LSP_GEN_TIMER msec."

Is not right because minimumLSPGenerationInterval/MinLSInterval would not
delay the initial generation of an LSP/LSA.  That was my initial point, I
don't know where a timer like LSP_GEN_TIMER is defined for ISIS/OSPF -- one
that delays the initial generation of an LSP/LSA.




About SPF_DELAY...  Yes, I-D.ietf-rtgwg-backoff-algo is the only place
where I see SPF_DELAY defined -- which makes it an existing (documented)
timer.  I think that I-D.ietf-rtgwg-backoff-algo should then be a Normative
reference.

Note also that I-D.ietf-rtgwg-backoff-algo does define something that
sounds to me just like LSP_GEN_TIMER:

   TIME_TO_LEARN_INTERVAL: This is the maximum duration typically needed
   to learn all the IGP events related to a single component failure
   (e.g., router failure, SRLG failure), e.g., 1 second.  It's mostly
   dependent on failure detection time variation between all routers
   that are adjacent to the failure.  Additionally, it may depend on the
   different IGP implementations across the network, related to
   origination and flooding of their link state advertisements.


It seems that it should be the right reference.

Thanks!

Alvaro.


>
>
> Brgds,
>
>
>
> *From:* Alvaro Retana [mailto:[e-mail]]
> *Sent:* Thursday, October 12, 2017 02:59
> *To:* LITKOWSKI Stephane OBS/OINIS
> *Cc:* The IESG; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07:
> (with DISCUSS and COMMENT)
>
>
>
> 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.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>