Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)

Vishnu Pavan Beeram <vishnupavan@gmail.com> Wed, 14 February 2018 15:05 UTC

Return-Path: <vishnupavan@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D418129C6A; Wed, 14 Feb 2018 07:05:21 -0800 (PST)
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 pCSSxu5P_gY1; Wed, 14 Feb 2018 07:05:14 -0800 (PST)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 6A7F5126BFD; Wed, 14 Feb 2018 07:05:14 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id o1so2029500pgn.4; Wed, 14 Feb 2018 07:05:14 -0800 (PST)
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=gWlxKsYNgutWQdo3q3OZdLKY5z/w7j1r9yaaa5uFL6o=; b=SMFxQOiJmZ3f4cH2RDSe44JhnMqqPX8VtNmfybzq8d8dpQE5Pp8bVFLnBcPov+5WOS R4DAen2HkwrEB/3KkMfuEIWTYWJGH7z+HQD5oXui+PIozGLzZ44ljR4/h7Mb1kSMZMOn 4icLxcsKVPDWRcYKNS/auhTv+bnztp/973WGrrefVoGV7J+mkY1qCYvL8Mw9rnQgvGed q2suh0wJPkFX4g0GlVtqyHrTipHHRk4o0MSixdel82hkeRSsrJFvdPspPLbxlu9daWRA hNk1L4cL3HJUv1rXSKIrRveJt7ao7wnPxhvVlDNkGuU1ain3+7g/pJdS3qIUyoxOATJ0 IAGw==
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=gWlxKsYNgutWQdo3q3OZdLKY5z/w7j1r9yaaa5uFL6o=; b=JaE+9+YPiES/WnihvCnVUjkPDKIqI8i3P1ZXGeQ7UC/FsIF5TEZ6XOaQ5mp6xGCTdB TyiSmu1fCpOCD+E9MPs635WcGRCQr+6Pos+W4xMzbGoSVq42/I3l9AN/AuKLt1aLtIaS pKuiZwUwt5EmDdsxcI+nJSppvWg6LmWBKklsctI9LA7lJLlMAxHvbLRwLREJKBqlcMuF iRvP2L/ONzgj/z+Ul8q4/JuuQ2rp97Guz7ivB4C/IIc0ZEu2J9N2dPloUkKi69JMszAw RUfeZbGO118p4vLlJ5INZxJKQvyTDDIlXMRPhKqv7wsUNKKM2Xcmrr6oGQS+98BqHrUs Gt+w==
X-Gm-Message-State: APf1xPABNIO3vqucZIVENgAgmY4qjebt9gpk9QJ+hiBw38BB2m0kj0hr WZsnwrlZYAt9GPeG+StUXT2d17HtMtrDb7IiGCg=
X-Google-Smtp-Source: AH8x225olIPaJf/eMl9EM24Z457OX9QGxjAd2mCAH07KFtJbDiGDkdFrUsgS5EkbMT2vbv4N0nrlPHGCXQ8kcUCj62E=
X-Received: by 10.99.171.70 with SMTP id k6mr1323932pgp.355.1518620713719; Wed, 14 Feb 2018 07:05:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.182.129 with HTTP; Wed, 14 Feb 2018 07:05:12 -0800 (PST)
In-Reply-To: <23D10DC7-C33C-4F19-8358-4B6D6B1FF5CF@kuehlewind.net>
References: <150644890311.20830.6212136664552694640.idtracker@ietfa.amsl.com> <CA+YzgTtqT9Ojs8Ed8fwW3FCLGVaJMTgCxsonH1Gxe-H7Q85orA@mail.gmail.com> <BBCF6104-8351-4C90-BD38-6A515DCAB9E5@kuehlewind.net> <CA+YzgTt77KmC1g2+C==c0F2BxWS0PEiuP-R0SNvWiv=_OO7s9Q@mail.gmail.com> <FFA062AD-A257-4AA8-8DE6-C7B03330DF81@kuehlewind.net> <CA+YzgTsqAyWY=gepg=moJCmDr=JDTop_sy-+SHJ8u1qn8g2jsQ@mail.gmail.com> <cfda7846-8637-f6c7-07dc-9979bd2fa7b2@labn.net> <CA+YzgTt-8g7-7juWg0zBqah=CPLVzktGacWa19rFoK5XoSMy4g@mail.gmail.com> <AD4CDD02-ECE6-49ED-886D-3B4631329496@kuehlewind.net> <CA+YzgTsetruY9Fk98dh_cDEnqYbA2H9m3+fW6LKuYniJLmucbA@mail.gmail.com> <2074ADF5-C8E1-4F4A-A524-554B26BEA681@kuehlewind.net> <CA+YzgTsY2NppQeWCLh9pTChK4n-GZxLgML30=feR8XVnLSN=-A@mail.gmail.com> <559976FE-E361-4CCF-A153-3D9F3B860D7B@kuehlewind.net> <CA+YzgTtRTHmkKCV1vY=otGtfeHAFKz6gZ3+6VyzYkzOXDWg0oQ@mail.gmail.com> <23D10DC7-C33C-4F19-8358-4B6D6B1FF5CF@kuehlewind.net>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Wed, 14 Feb 2018 10:05:12 -0500
Message-ID: <CA+YzgTtyq-ep4Ejg8eMV0QJAZ_ERu7RXZFESEwJ=wbxSY5RDCQ@mail.gmail.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: Lou Berger <lberger@labn.net>, TEAS WG Chairs <teas-chairs@ietf.org>, The IESG <iesg@ietf.org>, "teas@ietf.org" <teas@ietf.org>, draft-ietf-teas-rsvp-te-scaling-rec@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1bdad8309f3505652d7003"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/9V6IrpMCn5qVKBRWgV5NqKYT-Nc>
Subject: Re: [Teas] Mirja Kühlewind's Discuss on draft-ietf-teas-rsvp-te-scaling-rec-06: (with DISCUSS and COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2018 15:05:21 -0000

Thanks for clearing the discuss!

I'll push in an update to the draft with the changes I proposed yesterday.

Regards,
-Pavan

On Wed, Feb 14, 2018 at 6:13 AM, Mirja Kuehlewind (IETF) <
ietf@kuehlewind.net> wrote:

> Hi Paven,
>
> thanks for the explanation and sorry for the finally quite long delay. I
> had just not enough of RSVP knowledge to figure out how you are detecting a
> node failure. Thanks for the explanation below. I also didn’t realize that
> the previous default refresh interval was recommended as 30 second, which
> seems high.
>
> Knowing that there is a mechanism to detect node failure and stop sending,
> I will clear my discuss now. Again thanks for the explanation and patient!
>
> I believe actually your newly proposed text is more clear and I would
> still recommend to use that. I believe what confused me most was the use of
> the term „retransmission“ in the current section 2.3. It’s not fully wrong
> but if your motivation is to maintain a shorter refresh interval (as
> previously used) in situation where it is unclear if state was refreshed
> with the last message, I would phrase it like this, as in our new proposed
> text.
>
> Mirja
>
>
>
> > Am 14.02.2018 um 03:21 schrieb Vishnu Pavan Beeram <
> vishnupavan@gmail.com>:
> >
> > Mirja, Hi!
> >
> > Glad that the proposed text helped in understanding this better.
> >
> > All that the text is trying to say is the following --
> > In traditional RSVP (2961 capable) implementations, the interval used
> for refreshing state associated with unacked Path/Resv messages is the same
> as the regular refresh interval (R). But since we are now advocating the
> use of a large value for R, it makes sense to maintain a distinction
> between the refresh interval for unacked Path/Resv messages and the regular
> refresh interval.
> >
> > Your concerns (if I understood them right) aren't really against the
> procedures discussed in <rsvp-te-scaling-rec>. They are against how
> traditional RSVP (2961 capable) works. Let me see if I can address those.
> Please see inline (prefixed VPB)..
> >
> > Regards,
> > -Pavan
> >
> > On Tue, Feb 13, 2018 at 3:49 PM, Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net> wrote:
> > Hi Pavan,
> >
> > thanks a lot! This text change did help me to at least understand better
> what you are proposing. I'm still concerned that in a situation where all
> messages probably have been lost in the rapid retry phase, which is an
> indication of congestion, you still keep sending messages with a rather low
> but still higher rate than in the regular refresh interval of 20min.
> > Can you explain why this is considered to be beneficial?
> >
> > [VPB] This is because RSVP can't determine how long congestion would
> last on the neighboring node and it is important for signaling state
> (Path/Resv) to be kept in sync between neighbors. The congestion may clear
> up a couple of seconds after the rapid-retry phase (for a particular
> message) is complete or it may clear up 24 hours later. As long as the
> neighbor is deemed UP (is able to maintain "hello" session), signaling
> state associated with that neighbor will keep getting refreshed (this is
> just how RSVP works). If the neighbor gets congested enough to bring down
> the corresponding hello session, then appropriate "signaling adjacency
> failure" actions (this may include state tear down) would come into play.
> >
> >
> > I believe using some kind of extended exponential back-off would still
> be more appropriate. Also e.g. if you actually send the message every 30s
> for e.g. 20 minutes and don’t get an ACK, you might still want to give up
> and log an error (termination condition), no? I hope that makes now sense
> to you?
> >
> > [VPB]  Let us assume that the implementation gives up after a few
> retries and stops refreshing state associated with unacked Path/Resv
> messages. What should happen to the "state" now? You can't retain the
> state, because there is no prescribed way of determining when to start
> refreshing the state again (Note -- neighbor never went down; hellos are
> intact; interface to the neighbor is still UP). If you can't retain the
> state, then you must tear it down. But that is too extreme an action to
> take (especially if the data-plane is intact). I hope that explains why
> implementations keep refreshing state.
> >
> >
> >
> > Mirja
> >
> >
> >
> > > Am 13.02.2018 um 19:13 schrieb Vishnu Pavan Beeram <
> vishnupavan@gmail.com>:
> > >
> > > Mirja, Hi!
> > >
> > > Thanks for the response!
> > > It doesn't seem like we can make progress here if I keep recycling the
> same set of responses. I seem to have exhausted the "this is normal RSVP
> soft-state signaling behavior" line of argument :)
> > >
> > > I don't want to spend too much time arguing about a subtlety that
> (probably) only folks who have implemented RSVP-TE understand. So, let me
> try a different take on this.
> > >
> > > How about the following changes to the document?
> > >
> > > **
> > > - Remove Section 2.3 (this takes out the contentious text)
> > >
> > > - Make the following change in Section 3
> > >   OLD:
> > >    o  MUST make the default value of the configurable refresh interval
> > >       be a large value (10s of minutes).  A default value of 20 minutes
> > >       is RECOMMENDED by this document.
> > >
> > >   NEW:
> > >    o  MUST make the default value of the configurable refresh interval
> > >       (R) be a large value (10s of minutes).  A default value of 20
> > >
> > >       minutes is RECOMMENDED by this document.
> > >    o  MUST use a separate refresh interval for refreshing state
> associated
> > >       with unacknowledged Path/Resv messages (uR).  A default value of
> > >       30 seconds is RECOMMENDED by this document.
> > >
> > > - Make the following change in Appendix A.
> > >   OLD:
> > >       (d) Periodic Retransmission Interval for unacknowledged Path/Resv
> > >       messages (uR) - 30 seconds (Section 2.3).
> > >       If the Retry-Limit (Rl) is 7, then it takes 31.5 seconds for the
> 7
> > >       rapid retransmit steps to max out (The last delay from message 6
> > >       to message 7 is 16 seconds).  After the 7 rapid retransmit steps
> > >       are maxed out, the router starts periodic retransmission on a
> > >       slower timer.  This document recommends the use of the
> traditional
> > >       default refresh interval value of 30 seconds for this periodic
> > >       retransmission interval.
> > >
> > >   NEW:
> > >       (d) Refresh interval for refreshing state associated with
> > >       unacknowledged Path/Resv messages (uR)- 30 seconds (Section 3).
> > >       The recommended refresh interval (R) value of 20 minutes (for an
> > >
> > >       implementation supporting RI-RSVP) can not be used for refreshing
> > >       state associated with unacknowledged Path/Resv messages. This
> > >       document recommends the use of the traditional default refresh
> > >       interval value of 30 seconds for uR.
> > > ***
> > >
> > > Let me know if the above changes address your concerns.
> > >
> > > Regards,
> > > -Pavan
> > >
> > > On Tue, Feb 13, 2018 at 9:22 AM, Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net> wrote:
> > > Hi Pavan,
> > >
> > > I believe you that there may be implementation that transmit
> indefinitely, however, that is not how I read RFC2961:
> > >
> > > " The staged retransmission will continue
> > >    until either an appropriate MESSAGE_ID_ACK object is received, or
> the
> > >    rapid retry limit, Rl, has been reached.“
> > >
> > > or
> > >
> > > „The sending node will retransmit the message until a message
> > >    acknowledgment is received or the message has been transmitted a
> > >    maximum number of times.“
> > >
> > > For me these sentences say that one should not retransmit anymore
> after the max number is reached. If this is implemented differently, that
> is a not safe behavior and need to be clarified. There must be a
> termination condition. It is not safe for the stability of the Internet to
> retransmit packets indefinitely. Packet loss can have may reason but
> continuous packet loss is a clear sign of congestion that one can not be
> ignored.
> > >
> > > Mirja
> > >
> > >
> > >
> > > > Am 12.01.2018 um 14:15 schrieb Vishnu Pavan Beeram <
> vishnupavan@gmail.com>:
> > > >
> > > > Mirja, Hi!
> > > >
> > > > I thought the following response (sent on Oct 5th 2017) addressed
> this concern.
> > > >
> > > > ** Copying text from an earlier email **
> > > > There is nothing new about Path and Resv messages getting
> transmitted indefinitely (this is normal soft-state signaling behavior).
> All that is being discussed in this section is how these transmissions get
> paced after the rapid retry limit is reached. The slower timer transmission
> will go on until either an ack is received (at which point the regular
> "refresh interval" comes into play) or the corresponding LSP instance state
> is torn down.
> > > > **
> > > >
> > > > Please let me know if this still doesn't address the concern. We can
> set up a call and walk through the base RSVP specs.
> > > >
> > > > Regards,
> > > > -Pavan
> > > >
> > > > On Fri, Jan 12, 2018 at 7:12 AM, Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net> wrote:
> > > > Hi Vishnu, hi all,
> > > >
> > > > sorry but I lost a little bit track of this and looking at this now
> the clarification provided below do not seem to address my concern. My
> concern is that for messages (that a MESSAGE_ID object with the ACK_Desired
> flag set), these messages would retransmit forever (even though only every
> 30s) and there is not stop criteria to finally give up (and report an
> error).
> > > >
> > > > Mirja
> > > >
> > > >
> > > > > Am 22.12.2017 um 08:44 schrieb Vishnu Pavan Beeram <
> vishnupavan@gmail.com>:
> > > > >
> > > > > Mirja, Hi!
> > > > >
> > > > > Please see if the responses above address your concerns. Please
> let us know if there are any issues with progressing this document.
> > > > >
> > > > > Regards,
> > > > > -Pavan
> > > > >
> > > > > On Mon, Nov 13, 2017 at 4:21 AM, Lou Berger <lberger@labn.net>
> wrote:
> > > > > Hi,
> > > > > Please see below.
> > > > >
> > > > > On 11/13/2017 5:57 AM, Vishnu Pavan Beeram wrote:
> > > > > Mirja, Hi!
> > > > >
> > > > > Apologize for the delayed reply.
> > > > > Please see inline for responses (prefixed VPB).
> > > > >
> > > > > Regards,
> > > > > -Pavan
> > > > >
> > > > > On Mon, Oct 16, 2017 at 6:25 AM, Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
> > > > >
> > > > >     Hi Vishnu,
> > > > >
> > > > >     I don’t think what you proposed is a clarification at all.
> RF2961
> > > > >     clearly reads to me that you should not retry any more after
> the
> > > > >     Rapid retry limit has been reached:
> > > > >
> > > > >
> > > > >     "Rl is the maximum number of times a message will be
> > > > >                 transmitted without being acknowledged.“
> > > > >
> > > > >
> > > > > Please not that this section applies to "a message containing a
> MESSAGE_ID object with the ACK_Desired flag set" and
> > > > >
> > > > > The ACK_Desired flag will typically be set only in trigger
> messages.
> > > > >
> > > > > This means that these procedure does not apply to normal RSVP
> refresh processing and that  normal RFC2205 defined Refresh Processing or
> Summary Refresh processing continues.
> > > > >
> > > > >
> > > > > [VPB] Yes. As per RFC2961, the retry limit (Rl) is the maximum
> number of times a message will be transmitted without being acknowledged.
> But this just governs the number of times you retransmit the message during
> the "rapid retransmission phase".
> > > > >
> > > > > RFC2961 is silent about what happens after the "rapid
> retransmission phase" is complete and this is the clarification that is
> being provided here in the <scaling-rec> draft.
> > > > >
> > > > > The draft is silent in general about anything that is *not*
> modified by the draft.  I think having the informative statement is
> appropriate.
> > > > >
> > > > > Note that the associated RSVP Path/Resv state doesn't get cleaned
> up after the "rapid retransmission" phase is complete. So at each
> subsequent refresh-interval, the unacked Path/Resv message will be sent out
> again (note that if there is no change in the state, the same MESSAGE_ID
> would get used). This behavior has always existed in RSVP-TE
> implementations -- so it is incorrect to deduce from the "RFC 2961" text
> above that the retransmission of the unacked Path/Resv will never happen
> after the "Rl" is reached.
> > > > >
> > > > >
> > > > > Agreed.
> > > > > Lou
> > > > >
> > > > >
> > > > >     Also RFC2961 suggests an initial Rf of 500ms with 7 retries
> and and
> > > > >     delta of 2, that means you will see the following retries:
> > > > >
> > > > >     1. after 500ms
> > > > >     2. after 1000ms
> > > > >     3. after 2000ms
> > > > >     4. after 4000ms
> > > > >     5. after 8000ms
> > > > >     6. after 16000ms
> > > > >     7. after 32000ms
> > > > >
> > > > >     and then give up. While you suggests to send all 300ms section
> > > > >     afterwards forever. That is not acceptable and can lead to
> congestion.
> > > > >
> > > > >
> > > > > No, that is not what is being suggested.
> > > > > RFC2961 suggests an Rf of 500ms with 3 retries and a delta of 2.
> So the rapid retransmissions would be:
> > > > > 1. after 500ms
> > > > > 2. after 1000ms
> > > > > 3. after 2000ms.
> > > > >
> > > > > With the proposal in the <scaling-rec> draft, you would try 7
> times and then stop the "rapid retransmission phase". So, what that means
> is that the rapid retransmission phase lasts 31.5 seconds (first retry is
> after 500ms and the seventh retry is after 32000ms). After this "rapid
> retransmission phase" is complete, you keep sending the message out every
> 30000ms (30seconds is not 300ms) until an acknowledgement is received.
> > > > >
> > > > > Hope this helps.
> > > > >
> > > > >
> > > > >
> > > > >     Mirja
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >      > Am 05.10.2017 um 22:27 schrieb Vishnu Pavan Beeram
> > > > >     <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>:
> > > > >
> > > > >      >
> > > > >      > Mirja, Hi!
> > > > >      >
> > > > >      > This was discussed in my response to Elwyn. I apologize for
> not
> > > > >     responding directly.
> > > > >      >
> > > > >      > RFC2961 doesn't discuss what to do with the retransmissions
> after
> > > > >     the retry limit is reached. It doesn't discuss how
> retransmissions
> > > > >     need to be paced after the rapid retries are stopped. Section
> 2.3
> > > > >     (ver 7) of the current draft clarifies this and proposes the
> use of
> > > > >     a "not so rapid (30secs)" retransmission interval.
> > > > >      >
> > > > >      > There were a couple of questions from this section that you
> > > > >     wanted to get discussed:
> > > > >      > ----
> > > > >      > (1) Why is there no termination criteria specified?
> > > > >      > There is nothing new about Path and Resv messages getting
> > > > >     transmitted indefinitely (this is normal soft-state signaling
> > > > >     behavior). All that is being discussed in this section is how
> these
> > > > >     transmissions get paced after the rapid retry limit is
> reached. The
> > > > >     slower timer transmission will go on until either an ack is
> received
> > > > >     (at which point the regular "refresh interval" comes into
> play) or
> > > > >     the corresponding LSP instance state is torn down.
> > > > >      >
> > > > >      > ----
> > > > >      > (2) Why couldn't the regular refresh interval be used for
> these
> > > > >     un-acked retransmissions?
> > > > >      > The primary goal of the retransmission is to eke out an
> > > > >     acknowledgement from the neighbor as quickly as you can. You
> can use
> > > > >     the same value as the the regular refresh interval provided it
> is
> > > > >     small enough (like in the case of the conventional refresh
> interval
> > > > >     of 30 secs) . However, we are recommending the use of a "large
> > > > >     refresh interval" (20 mins) in the RI-RSVP technique -- we
> can't
> > > > >     wait that long for retrying the transmission of an unacked
> message.
> > > > >      >
> > > > >      > Consider a rudimentary state machine with the following
> states
> > > > >     (assuming the defaults suggested in the Appendix of the draft):
> > > > >      > - first retransmit (exponential back off)
> > > > >      > - second retransmit (exponential back off)
> > > > >      > ...
> > > > >      > - seventh retransmit (exponential back off)
> > > > >      > - 30s retransmission
> > > > >      > - 20m refresh (regular refresh timer)
> > > > >      >
> > > > >      > At any point when the Ack is received, you transition to
> the 20m
> > > > >     refresh state.
> > > > >      >
> > > > >      > ---
> > > > >      >
> > > > >      > Do these two responses adequately answer your questions?
> > > > >      >
> > > > >      > Regards,
> > > > >      > -Pavan
> > > > >      >
> > > > >      > On Thu, Oct 5, 2017 at 7:57 AM, Mirja Kuehlewind (IETF)
> > > > >     <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
> > > > >      > Hi Pavan,
> > > > >      >
> > > > >      > I don’t see any changes in the new version that addresses
> may
> > > > >     actual discuss on section 2.1.3 (now section 2.3). Can you
> please
> > > > >     clarify?
> > > > >      >
> > > > >      > Thanks,
> > > > >      > Mirja
> > > > >      >
> > > > >      >
> > > > >      > > Am 28.09.2017 um 05:45 schrieb Vishnu Pavan Beeram
> > > > >     <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>:
> > > > >      > >
> > > > >      > > Mirja, Hi!
> > > > >      > >
> > > > >      > > Thanks for the review. We just posted a new revision
> (-07) to
> > > > >     address the Gen-Art review comments. Please go through the new
> diffs
> > > > >     (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-
> scaling-rec-07
> > > > >     <https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-
> scaling-rec-07>)
> > > > >     and let us know if additional changes are required.
> > > > >      > >
> > > > >      > > Also, please go through the responses provided to the
> other
> > > > >     review comments and let us know if there are still any
> unanswered
> > > > >     questions.
> > > > >      > >
> > > > >      > > Regards,
> > > > >      > > -Pavan
> > > > >      > >
> > > > >      > >
> > > > >      > >
> > > > >      > > On Tue, Sep 26, 2017 at 2:01 PM, Mirja Kühlewind
> > > > >     <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote:
> > > > >      > > Mirja Kühlewind has entered the following ballot position
> for
> > > > >      > > draft-ietf-teas-rsvp-te-scaling-rec-06: Discuss
> > > > >      > >
> > > > >      > > When responding, please keep the subject line intact and
> reply
> > > > >     to all
> > > > >      > > email addresses included in the To and CC lines. (Feel
> free to
> > > > >     cut this
> > > > >      > > introductory paragraph, however.)
> > > > >      > >
> > > > >      > >
> > > > >      > > Please refer to
> > > > >     https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > >     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> > > > >      > > for more information about IESG DISCUSS and COMMENT
> positions.
> > > > >      > >
> > > > >      > >
> > > > >      > > The document, along with other ballot positions, can be
> found here:
> > > > >      > >
> > > > >     https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-
> scaling-rec/ <https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-
> scaling-rec/>
> > > > >
> > > > >      > >
> > > > >      > >
> > > > >      > >
> > > > >      > >
> > > > >     ------------------------------------------------------------
> ----------
> > > > >      > > DISCUSS:
> > > > >      > >
> > > > >     ------------------------------------------------------------
> ----------
> > > > >      > >
> > > > >      > > I'm uncertain what section 2.1.3. actually recommends. My
> > > > >     understanding is that
> > > > >      > > it is recommend to still send retransmit some message
> even if
> > > > >     the Rl was
> > > > >      > > reached and to that every 30s basically forever. First of
> all I
> > > > >     think this
> > > > >      > > still needs a termination criteria when to stop to try to
> > > > >     retransmit finally.
> > > > >      > > And the I don't understand why this is needed, instead of
> e.g.
> > > > >     just using a
> > > > >      > > larger Rl value? Can you please clarify!
> > > > >      > >
> > > > >      > >
> > > > >      > >
> > > > >     ------------------------------------------------------------
> ----------
> > > > >      > > COMMENT:
> > > > >      > >
> > > > >     ------------------------------------------------------------
> ----------
> > > > >      > >
> > > > >      > > I fully agree with the gan-art review (Thanks Elwyn!) and
> > > > >     Alvaro, that this
> > > > >      > > reads from time to time like a BCP but is actually a
> extension
> > > > >     specification. I
> > > > >      > > would strongly recommend to apply the changes proposed by
> the
> > > > >     gen-art review,
> > > > >      > > and there is also a very detailed list of nits/edits that
> > > > >     should probably be
> > > > >      > > applied. Please have a look at that!
> > > > >      > >
> > > > >      > >
> > > > >      > > _______________________________________________
> > > > >      > > Teas mailing list
> > > > >      > > Teas@ietf.org <mailto:Teas@ietf.org>
> > > > >      > > https://www.ietf.org/mailman/listinfo/teas
> > > > >     <https://www.ietf.org/mailman/listinfo/teas>
> > > > >      > >
> > > > >      >
> > > > >      >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Teas mailing list
> > > > > Teas@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/teas
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > Teas mailing list
> > > Teas@ietf.org
> > > https://www.ietf.org/mailman/listinfo/teas
> > >
> >
> >
>
>