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

Alia Atlas <akatlas@gmail.com> Mon, 12 March 2018 20:04 UTC

Return-Path: <akatlas@gmail.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 25C08126DD9; Mon, 12 Mar 2018 13:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 41tbj1KGK9nv; Mon, 12 Mar 2018 13:04:44 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5461126CF9; Mon, 12 Mar 2018 13:04:35 -0700 (PDT)
Received: by mail-oi0-x22e.google.com with SMTP id c18so13380517oiy.9; Mon, 12 Mar 2018 13:04:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gB1i39k0qQBYZfhMxiyJbfOtMxqOQrHRpWL8vd+WXdg=; b=jUQvUq89R/iFiHOMa7xxvuGxFfFmngianBd/v2fxL9u0bfdrs5JQGW4OKC9r0pJ2Dh uiU9rsEcFvlUnQwAs5p1FKBihKribrr7crmdmhmv4Y9aN9+Fxjcv84c9lG7YYzCaAHq8 K/W3R3H+mBNSxntci6o9YXeMI46m2pHuTvmXr0i1EcBdswWptW98HkEfFKNWsImd3D/X x/bsT0CvwiYYqdRgOuMSQsbMz/x3OH29TEvdsUyOmyf+gTCKKDHdSKB3tWEiIf0/Fgzg 9/T4HP3RunMCUFVA061sunKUmisR/c5UApfKGOCxv7mchK7F73frKh4LfGMXYniN5Qiy uAEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gB1i39k0qQBYZfhMxiyJbfOtMxqOQrHRpWL8vd+WXdg=; b=RiuKrU1FYDLrGhn0dsfj8TbaX9KJiA76wd1Vy+hOZ3PpSMSCC2tfgsnEdhwIb4480t zzE0F2XiqLWkp9rS9EaRIyAHTv+O/uOCu8UW5E3fBPlo1ISVb7oV2U4YqUfdMpTx9cd1 InHKXRMTNjBwNowWJrSS62KWbqqx0b34YR4kDJMd8nn+r3qgkMB4cjMpecJyn7a+VpxS Rqy8tv6336+qpBzq0er4b3872PSri8WLef2tWMCJQNSIICY3Bw8FfZuPE/QMl9PCrtJE bRpcxdScVkuRFft3iwejCZpQ8eEEDtC/R6yCS0xz6RDFodDDB04ivzMqgb2s/yMN0jfg Kn3w==
X-Gm-Message-State: AElRT7H9bHSoAiBhABoz39LY5ILAaIAWzrYIFrYKGYEaJ+CIfbUy6Zj2 d8tXZQ8+LzWWPQ3mausIBoXLu6EECASB/QTFmAA=
X-Google-Smtp-Source: AG47ELtk/KX1QdXTc8h8LYEe5LDH2f9PKbA7bHq+cAiteWc8ZPhfXB/3pljlaqQ1/sCD3XX265VrkBrsF9SSBtXRKKM=
X-Received: by 10.202.3.198 with SMTP id 189mr5346186oid.132.1520885074815; Mon, 12 Mar 2018 13:04:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:4439:0:0:0:0:0 with HTTP; Mon, 12 Mar 2018 13:04:34 -0700 (PDT)
In-Reply-To: <11836_1519842985_5A96F6A9_11836_240_1_53C29892C857584299CBF5D05346208A479B3D9E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <151910656889.29750.3686523183770186132.idtracker@ietfa.amsl.com> <11836_1519842985_5A96F6A9_11836_240_1_53C29892C857584299CBF5D05346208A479B3D9E@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Alia Atlas <akatlas@gmail.com>
Date: Mon, 12 Mar 2018 16:04:34 -0400
Message-ID: <CAG4d1rezzMkfvW3-Uxh1kvyYNQu+_kuaDYV3Gjzf2CKCd2bK9w@mail.gmail.com>
Subject: Re: Alvaro Retana's Discuss on draft-ietf-rtgwg-backoff-algo-07: (with DISCUSS and COMMENT)
To: Bruno Decraene <bruno.decraene@orange.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "rtgwg@ietf.org" <rtgwg@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-rtgwg-backoff-algo@ietf.org" <draft-ietf-rtgwg-backoff-algo@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c0463ca0f31605673ca657"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/P3tchPgQ8NCkvxMGJuHSFgfZZrA>
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: Mon, 12 Mar 2018 20:04:47 -0000

Hi Alvaro, Deborah & Bruno,

Does the most recent version (draft-ietf-rtgwg-backoff-algo-09) resolve the
concerns?
It would be excellent to have this approved before Weds at IETF 101.

I am happy to approve an updated draft being submitted, if necessary,
before IETF starts.


Thanks,
Alia

On Wed, Feb 28, 2018 at 1:36 PM, <bruno.decraene@orange.com>; wrote:

> Alvaro,
>
> Please find below a follow up on one point
>
> > From: DECRAENE Bruno IMT/OLN
>  > Sent: Tuesday, February 27, 2018 11:44 AM
>
>  [...]
>
> >  > -----Original Message-----
>  >  > From: Alvaro Retana [mailto:aretana.ietf@gmail.com]
>  >  > Sent: Tuesday, February 20, 2018 7:03 AM
>
> [...]
>
> >  > ------------------------------------------------------------
> ----------
>  >  > COMMENT:
>  >  > ------------------------------------------------------------
> ----------
>
> [...]
>
> >
>  >  > (2.3) For completeness, the HOLDDOWN_TIMER expiration events (5 and
> 6) should
>  >  > include resetting all the timers, just in case...and to be
> consistent with the
>  >  > initialization description.
>  >
>  > [Bruno] Good point a priori. However, I don't think anything needs to
> be changed because:
>  > - SPF_TIMER must not be reset as it can still run (if LONG_SPF_DELAY >
>  > HOLDDOWN_INTERVAL)
>  > - HOLDDOWN_TIMER has already expired by hypothesis
>  > - For transition 5 (from LONG_WAIT state), LEARN_TIMER has already
> expired by hypothesis.
>  > - For transition 6 (from SHORT_WAIT state) LEARN_TIMER has already
> expired because of the
>  > following constraint: " The
>  >    HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than
> the
>  > TIME_TO_LEARN_INTERVAL."
>
> Thinking more about this,
> Given that transition 6 should not be used if the constraint is enforced
> on the timers, but transition 6 is still documented for completeness and
> robustness, I think it makes sense to talk about the LEARN_TIMER during
> this transition 6.
> But actually, this is already in the draft:
>
>    Transition 6: HOLDDOWN_TIMER expiration, while in SHORT_WAIT.
>
>    Actions on event 6:
>    o  Deactivate LEARN_TIMER.
>    o  Transition to QUIET state.
>
> https://tools.ietf.org/html/draft-ietf-rtgwg-backoff-algo-08#section-5.1
>
> Thanks
> --Bruno
>
> ____________________________________________________________
> _____________________________________________________________
>
> 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.
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>