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

<stephane.litkowski@orange.com> Thu, 12 October 2017 15:35 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7681134515; Thu, 12 Oct 2017 08:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level:
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtr_c5tYIP9S; Thu, 12 Oct 2017 08:35:50 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21E2134520; Thu, 12 Oct 2017 08:35:49 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 696A4C058B; Thu, 12 Oct 2017 17:35:48 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 44D274005B; Thu, 12 Oct 2017 17:35:48 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0361.001; Thu, 12 Oct 2017 17:35:47 +0200
From: stephane.litkowski@orange.com
To: Alvaro Retana <aretana.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-rtgwg-uloop-delay@ietf.org" <draft-ietf-rtgwg-uloop-delay@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "chrisbowers.ietf@gmail.com" <chrisbowers.ietf@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "Acee Lindem (acee) (acee@cisco.com)" <acee@cisco.com>
Subject: RE: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)
Thread-Index: AQHTQgl2nftSREwoOEyh3YJkmj42GKLeV4YAgADteYCAAIE/oIAAWAmAgAA8n5A=
Date: Thu, 12 Oct 2017 15:35:47 +0000
Message-ID: <24816_1507822548_59DF8BD4_24816_233_1_9E32478DFA9976438E7A22F69B08FF921EA87342@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <150766865027.13436.4602054386632294983.idtracker@ietfa.amsl.com> <12174_1507712861_59DDDF5D_12174_52_1_9E32478DFA9976438E7A22F69B08FF921EA865C2@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <CAMMESsxEFugQRJx4PG9GupPPvg-eZzz99r-e9EOxHPzEU_n51w@mail.gmail.com> <26205_1507790863_59DF100F_26205_313_1_9E32478DFA9976438E7A22F69B08FF921EA86D8A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <CAMMESszwJqP3j6G+BBwkQLL=o33gLhR+8XH7s_M=DzBX5o_g0Q@mail.gmail.com>
In-Reply-To: <CAMMESszwJqP3j6G+BBwkQLL=o33gLhR+8XH7s_M=DzBX5o_g0Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.4]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921EA87342OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/V4lOsXK7zR3fTyXQQxXH6Ol0ldc>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Oct 2017 15:35:54 -0000

Hi Alvaro,

Maybe the definition we gave for the LSP_GEN_TIMER is wrong (I think we defined more the usage rather than giving the exact definition), because we are talking about the local LSA/LSP regeneration.
We usually slowdown the generation in case of flaps to aggregate events and to prevent propagation of all topology changes.


From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
Sent: Thursday, October 12, 2017 15:57
To: LITKOWSKI Stephane OBS/OINIS
Cc: The IESG; draft-ietf-rtgwg-uloop-delay@ietf.org; rtgwg-chairs@ietf.org; chrisbowers.ietf@gmail.com; rtgwg@ietf.org; Acee Lindem (acee) (acee@cisco.com)
Subject: Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT)

On Thu, Oct 12, 2017 at 2:47 AM, <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>> 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:aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>]
Sent: Thursday, October 12, 2017 02:59
To: LITKOWSKI Stephane OBS/OINIS
Cc: The IESG; draft-ietf-rtgwg-uloop-delay@ietf.org<mailto:draft-ietf-rtgwg-uloop-delay@ietf.org>; rtgwg-chairs@ietf.org<mailto:rtgwg-chairs@ietf.org>; chrisbowers.ietf@gmail.com<mailto:chrisbowers.ietf@gmail.com>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
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, <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>> 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.


_________________________________________________________________________________________________________________________

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.